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 17 Next »

Overview

This page describes the features of the SDX Layer 3 use case.

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 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 SDX peers configurations with appropriate printout command. A new command named bgp-peers is introduced for this purpose.
  • Peer-connectivity should consider the configured association when creating the relevant p-t-p intents.
  • FIB component should consider the configured association when creating the relevant m-t-p intents.

Sample 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"
  }]}}}

SDX with route server

Description

The association of peers with interfaces allows the SDX support of route server functionality. In a typical scenario all the BGP routers of Service Providers (SPs) as well as the internal BGP speaker(s) belong to the same sub-net. However, contrary to the legacy 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.

Sample 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