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 26 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.

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 and route server

Description

The association of peers with interfaces allows the SDX support of route server functionality. In a typical scenario for SDX 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 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