Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Next »

Overview

This page describes the Software Defined Internet Exchange Point - Layer 3 application (SDX-L3 or sdxl3 in ONOS nomenclature). SDX-L3 is an application that extends the existing SDN-IP application of ONOS in order to support software defined Internet Exchange Points (IXP), i.e. an infrastructure where various Service Providers (SP) can exchange traffic between their Autonomous Systems (AS).

This description makes use of the SDN-IP application principles and terminology, thus the reader is advised to read the SDN-IP Architecture and SDN-IP User Guide before proceeding to the rest of the application description.

 

Description

Although SDN-IP application can be used for the interconnection of different IP networks and for its behavior as as transit AS, there are some factors that prevent the SDN-IP network from being characterized as SDX. The main reasons for that are the following:

  • In a typical IXP scenario, the border routes of the interconnected AS have interfaces in the same sub-net, i.e. the sub-net of the IXP. This is not currently supported by SDN-IP since the border routers, i.e., the BGP peers, should belong in different networks. Thus, in SDN-IP no explicit association between BGP peers and interface of the SDN-IP network is necessary. ONOS is able to find the interface towards a BGP peer automatically by matching the interface configured sub-net with the BGP peer IP address.
  • IXP are combined with route servers, which allow the direct connection with other peering SPs. This means that the traffic originating from SP1 towards SP2 can be forwarded directly from SP1's border router towards the SP2's border router without the intermediate hop to an IXP's router. This is not currently supported by SDN-IP since all traffic between peering ASs should pass through an SDN-IP network internal router.

Currently the SDX-L3 application offers the above features. First, with the association of peers with interfaces, which allows border routers belonging in the same sub-net and lets the user to explicitly assign the connection point of each BGP peer. Second, by allowing direct traffic between SPs through the SDX-L3 network without the need for the hop towards an internal BGP router. Of course, in order to achieve this type of direct communication, the BGP peers for both the SPs should belong to the same sub-net.

Application setup

SDX-L3 is implemented as the ONOS's sdxl3 or org.onosproject.sdxl3 application. SDX-L3 integrates the SDX-related features to the existing SDN-IP functionality and the sdnip application should be deactivated in order to activate sdxl3. Additionally, since SDX-L3 implements a different proxy-ARP handling than the one implemented in the proxy-ARP application, proxyarp should be deactivated as well as.

onos> app deactivate org.onosproject.sdnip org.onosproject.proxyarp
onos> app activate org.onosproject.sdxl3

SDX-L3 configuration should be placed in the network-cfg.json file in the config directly, and it will be read in automatically at startup as in the SDN-IP case. The application use a configuration identical to SDN-IP along with additional configuration details that are specific for SDX-L3 and are optional. These details are explained below in this page. 

Routing policies

In a typical IXP case, routing policies can be applied. SDX-L3 system makes use of the same architecture used in SDN-IP, thus iBGP implementation is integrated in ONOS which is used for the communication with the internal BGP speakers. Since, the ONOS BGP implementation is passive, the routing information is set by the internal BGP speaker from the exIn the SDX-L3 network the policies are a

SDX-L3 features

Association of peers with interfaces

Description

There is the case that multiple peers belong to the same AS and are connected through different connection points to the SDX-L3 network controlled by ONOS. In this case, the user should be able to explicitly define the connection points to each peer. This is necessary since the identification of the appropriate interface by the application itself is not enough. Overlapping or identical sub-nets may exist in the "ports" section of the network configuration and thus the identification of which connection point should be used for a given peer is not straightforward.

This association is supported by the sdxl3 app and is introduced either by appropriate configuration in network-cfg.json file or by the command line handlers provided by the sdxl3 application during runtime. Apart from the associated interface, the user is able to assign an optional name to each BGP peer.

Specifications

The specifications applying to the above feature are the following:

  • All the SDX-L3 related functionality is handled by an application, namely sdxl3, that cannot be active along with sdnip application.
  • Different peering sessions can be maintained for the same AS.
  • Interfaces towards overlapping and/or identical sub-nets can be defined in the "ports" -> "interfaces" section of network configuration. These interfaces can be used for BGP peering sessions and, in order be be referenced to, a "name" must be specified for them.
  • Optionally, a "name" attribute can be assigned to a configured peer.
  • In case that a given peer's IP address matches with two or more interfaces, it is recommended that the user should explicitly specify the interface that applies.
  • Backwards compatibility is kept with existing configuration structure.
  • Backwards compatibility is kept with existing configuration commands.

  • New functionality is also supported by peer-add-details and peer-remove-details command.

  • The user is able to monitor such BGP peers configurations with appropriate printout command. A new command named bgp-peers is introduced for this purpose.
  • Peer-connectivity considers the configured association when creating the relevant p-t-p intents.
  • FIB component considers the configured association when creating the relevant m-t-p intents.

Configuration

An example of a network configuration supported by the proposed feature is the following: network-cfg.json

This configuration is based on the one described in the SDN-IP tutorial. New peers with IP addresses 10.0.1.2 and 10.0.1.129 have been added in the topology, all of them belonging to the same sub-net 10.0.1.0/24 (AS1). Peer 10.0.1.2 is connected through a different connection point than the others to the SDX. Peer 10.0.1.129 is connected through the same connection point as 10.0.1.1 but uses vlan-id 100.

The following part describes the structure of the new attribute proposed for the association between peers and interfaces. It takes as prerequisite that a "name" has been added to  "ports" -> "interfaces" in order for the interfaces to be referenced to. The "name"  for "bgpPeers" is optional.

"apps" : {
"org.onosproject.sdxl3": {
  "providers": {
    "bgpPeers": [
      {
        "name": "AS1-Router1",
        "ip": "10.0.1.1",
        "connectPoint": "of:00000000000000a1/1",
        "intfName": "AS1-conn1"
  }]}}}

CLI commands

The configuration can be added during run-time with the appropriate CLI commands.

Addition of peer-specific details

peer-add-details

This command adds the details of an external BGP peer, i.e. BGP peer name (optionally), BGP peer IP, connect point of the BGP peer, name of configured interface for the BGP peer.

An example of the command that corresponds to the above scenario is the following:

peer-add-details -n=AS1-Router1 10.0.1.1 of:00000000000000a1/1 AS1-conn1

After the successful execution of the above command, a new association of specified peer with the named interface on specified port is introduced and activated.

Removal of peer-specific details

peer-remove-details

This command removes the details previously specified for an external BGP peer. Only the IP address of the peer should be given as a command argument.

An example of the command that corresponds to the above scenario is the following:

peer-remove-details 10.0.1.1

After the execution of the above command, a previous defined association of the specified peer with a configured interface no longer exists.

List of peer-specific information

bgp-peers

This command lists all the BGP peers specified in the system. Depending on whether details have been specified for a given peer or not, it behaves as follows:

  • If no details have been previously specified for a given peer, only the peer IP address is listed.
  • If details have been previously added, all the specified details will be listed by the command for this peer.

SDX-L3 and route server

Description

The association of peers with interfaces allows the SDX-L3 network to support route server functionality. In a typical scenario for SDX-L3 all the BGP routers of SPs as well as the internal BGP speaker(s) belong to the same sub-net. However, contrary to the legacy SDN-IP functionality, when the internal BGP speaker(s) is configured as route server it provides the necessary transparency so that peering SPs still appear to be directly connected through the SDX. Therefore, during route propagation between SPs the mediation of the route server is invisible outside of the SDX.

The association of peers with interfaces allows the support of route server functionality since the peer connectivity and the FIB component consider the peer-to-interface mapping when creating the relevant p-t-p and m-t-p intents, respectively. However, ARP requests for direct traffic between the SPs' routers are not handled by legacy functionality.

Specifications

The specifications applying to the above feature are the following:

  • Internal BGP speaker should support route server functionality (this is not related with ONOS itself).
  • The feature for the association of peers with interfaces should be supported.
  • Proxy-ARP functionality handles (and not reject) ARP requests between configured BGP routers of SPs, i.e. external peers.
  • Since sdxl3 implements its own proxy-ARP handling, when activating sdxl3 application, the ONOS proxyarp application should be deactivated.

Configuration

An example of a network configuration for ONOS operating along with a route server is the following: network-cfg.json

This configuration defines two external peers, namely "AS65001-R1" and "AS65002-R2", that belong to the same sub-net 10.0.0.3/24 as the internal BGP speaker. The relevant python creating the mininet topology is the following: route-server-conf.py.The necessary quagga files for "AS65001-R1", "AS65002-R2" and the internal route server are: quagga1.conf, quagga2.conf, and quagga-sdn.conf, respectively.

  • No labels