From 617fd7ddfb1d0d22052a57e6b28b4573a3b7b52b Mon Sep 17 00:00:00 2001 From: Colin Dixon Date: Thu, 18 Aug 2016 16:53:19 -0400 Subject: [PATCH] Migrate BGP PCEP user docs to rst Change-Id: Iaa8e4182292e99bbf6dbb0b0e869d0b0f7aeaffd Signed-off-by: Colin Dixon --- .../bgp-monitoring-protocol-user-guide.rst | 153 +++ docs/user-guide/bgp-user-guide.rst | 996 ++++++++++++++++++ docs/user-guide/pcep-user-guide.rst | 340 ++++++ .../bgpcep/odl-bgpcep-bgp-all-user.adoc | 910 +--------------- .../asciidoc/bgpcep/odl-bgpcep-bmp-user.adoc | 134 +-- .../bgpcep/odl-bgpcep-pcep-all-user.adoc | 280 +---- 6 files changed, 1492 insertions(+), 1321 deletions(-) create mode 100644 docs/user-guide/bgp-monitoring-protocol-user-guide.rst create mode 100644 docs/user-guide/bgp-user-guide.rst create mode 100644 docs/user-guide/pcep-user-guide.rst diff --git a/docs/user-guide/bgp-monitoring-protocol-user-guide.rst b/docs/user-guide/bgp-monitoring-protocol-user-guide.rst new file mode 100644 index 000000000..5ea5833d7 --- /dev/null +++ b/docs/user-guide/bgp-monitoring-protocol-user-guide.rst @@ -0,0 +1,153 @@ +BGP Monitoring Protocol User Guide +================================== + +Overview +-------- + +The OpenDaylight Karaf distribution comes preconfigured with baseline +BMP configuration. + +- **32-bmp.xml** (initial configuration for BMP messages handler + service provider and BMP client/server dispatcher settings) + +- **42-bmp-example.xml** (sample initial configuration for the BMP + Monitoring Station application) + +Configuring BMP +--------------- + +Server Binding +~~~~~~~~~~~~~~ + +The default shipped configuration will start a BMP server on +0.0.0.0:12345.You can change this behavior in **42-bmp-example.xml**: + +.. code:: xml + + + prefix:bmp-monitor-impl + example-bmp-monitor + + 12345 + ... + + +- **binding-address** - adress on which BMP will be started and listen; + to change value, uncomment then line first + +- **binding-port** - port on which the address will be started and + listen + +Multiple instances of the BMP monitoring station (**bmp-monitor-impl** +module) can be created. However, each instance must have a unique pair +of **binding-address** and **binding-port** + +Active mode +~~~~~~~~~~~ + +OpenDaylight’s BMP might be configured to act as an active party of the +connection (ODL BMP < = > Monitored router). To enable this +functionality, configure monitored-router with mandatory parameters: + +- address (must be unique for each configured "monitored-router"), + +- port, + +- active. + +See following example from 42-bmp-example.xml: + +.. code:: xml + + +
192.0.2.2
+ 1234 + true + + +Configuration through RESTCONF +------------------------------ + +Server Binding +~~~~~~~~~~~~~~ + +**URL:** +*`http://:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor :8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor>`__* + +**Content-Type:** application/xml + +**Method:** PUT + +**Body:** + +.. code:: xml + + + example-bmp-monitor + x:bmp-monitor-impl + + bmp-dispatcher + global-bmp-dispatcher + + + x:binding-codec-tree-factory + runtime-mapping-singleton + + + x:extensions + global-rib-extensions + + 0.0.0.0 + + x:dom-async-data-broker + pingpong-broker + + 12345 + + +- change values for **binding-address** and/or **binding-port** + +Active mode +~~~~~~~~~~~ + +**URL:** +*`http://:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor :8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor>`__* + +**Content-Type:** application/xml + +**Method:** PUT + +**Body:** + +.. code:: xml + + + example-bmp-monitor + x:bmp-monitor-impl + + bmp-dispatcher + global-bmp-dispatcher + + + x:binding-codec-tree-factory + runtime-mapping-singleton + + + x:extensions + global-rib-extensions + + 0.0.0.0 + + x:dom-async-data-broker + pingpong-broker + + 12345 + +
127.0.0.1
+ 1234 + true + + + +- change values for **address** and **port** + diff --git a/docs/user-guide/bgp-user-guide.rst b/docs/user-guide/bgp-user-guide.rst new file mode 100644 index 000000000..e27ce4141 --- /dev/null +++ b/docs/user-guide/bgp-user-guide.rst @@ -0,0 +1,996 @@ +BGP User Guide +============== + +Configuring BGP +--------------- + +The OpenDaylight Karaf distribution comes pre-configured with a baseline +BGP configuration. You can find it in the ``etc/opendaylight/karaf`` +directory and it consists of two files: + +``31-bgp.xml`` + defines the basic parser and RIB support + +``41-bgp-example.xml`` + contains a sample configuration which needs to be customized to your + deployment) + +The next sections will describe how to configure BGP manually or using +RESTCONF. + +RIB +~~~ + +The configuration of the Routing Information Base (RIB) is specified +using a block in the ``41-bgp-example.xml`` file. + +.. code:: xml + + + prefix:rib-impl + example-bgp-rib + example-bgp-rib + 64496 + 192.0.2.2 + 192.0.2.3 + ... + + +- **type** - should always be set to ``prefix:rib-impl`` + +- **name** and **rib-id** - BGP RIB Identifier, you can specify + multiple BGP RIBs by having multiple the above ``module`` blocks. + Each such RIB must have a unique rib-id and name. + +- **local-as** - the local AS number (where OpenDaylight is deployed), + we use this in best path selection + +- **bgp-id** - the local BGP identifier (the IP of the VM where + OpenDaylight is deployed), we use this in best path selection. + +- **cluster-id** - cluster identifier, optional, if not specified, BGP + Identifier will be used + +Depending on your BGP router, you might need to switch from linkstate +attribute type 99 to 29. Check with your router vendor. Change the field +iana-linkstate-attribute-type to true if your router supports type 29. +This snippet is located in ``31-bgp.xml`` file. + +.. code:: xml + + + prefix:bgp-linkstate + bgp-linkstate + true + + +- **iana-linkstate-attribute-type** - IANA has issued an early + allocation for the BGP linkstate path attribute (=29). To preserve he + old value (=99) set this to to false; to use IANA assigned type set + the value to true or remove it as it’s true by default. + +BGP Peer +~~~~~~~~ + +The initial configuration is written so that it will be ignored to +prevent the client from starting with default configuration. Therefore +the first step is to uncomment the module containing bgp-peer. + +.. code:: xml + + + prefix:bgp-peer + example-bgp-peer + 192.0.2.1 + 180 + ibgp + + prefix:rib-instance + example-bgp-rib + + ... + + +- **name** - BGP Peer name, in this configuration file you specify + multiple BGP Peers by replicating the above ``module`` block. Each + peers must have a unique name. + +- **host** - IP address or hostname of BGP speaker where OpenDaylight + should connect to the peer + +- **holdtimer** - hold time in seconds + +- **peer-role** - If peer role is not present, default value "ibgp" + will be used (other allowed values are "ebgp" and "rr-client"). This + field is case-sensitive. + +- **rib** - BGP RIB identifier + +Configure Connection Attributes (Optional) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. code:: xml + + + prefix:timed-reconnect-strategy + example-reconnect-strategy + 1000 + 180000 + 2.00 + 5000 + + netty:netty-event-executor + global-event-executor + + + +- **min-sleep** - minimum sleep time (miliseconds) in between reconnect + tries + +- **max-sleep** - maximum sleep time (miliseconds) in between reconnect + tries + +- **sleep-factor** - power factor of the sleep time between reconnect + tries, i.e., the previous sleep time will be multiplied by this + number to determine the next sleep time, but never exceed + **max-sleep** + +- **connect-time** - how long BGP should wait (miliseconds) for the TCP + connect attempt, overrides default connection timeout dictated by + TCP. + +BGP Speaker Configuration +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The previous entries described configuration of a BGP connections +initiated by OpenDaylight. OpenDaylight can also accept incoming BGP +connections. + +The configuration of BGP speaker is located in: ``41-bgp-example.xml``: + +.. code:: xml + + + prefix:bgp-peer-acceptor + bgp-peer-server + + + + + + ... + + + prefix:bgp-peer-registry + global-bgp-peer-registry + + + +- Changing binding address: Uncomment tag binding-address and change + the address to e.g. *127.0.0.1*. The default binding address is + *0.0.0.0*. + +- Changing binding port: Uncomment tag binding-port and change the port + to e.g. *1790*. The default binding port is *179* as specified in + `RFC 4271 `__. + +Incomming BGP Connections +~~~~~~~~~~~~~~~~~~~~~~~~~ + +**The BGP speaker drops all BGP connections from unknown BGP peers.** +The decision is made in component bgp-peer-registry that is injected +into the speaker (The registry is configured in ``31-bgp.xml``). + +To add a BGP Peer configuration into the registry, it is necessary to +configure regular BGP peer just like in example in +``41-bgp-example.xml``. Notice that the BGP peer depends on the same +bgp-peer-registry as bgp-speaker: + +.. code:: xml + + + prefix:bgp-peer + example-bgp-peer + 192.0.2.1 + ... + + prefix:bgp-peer-registry + global-bgp-peer-registry + + ... + + +The BGP peer registers itself into the registry, which allows incoming +BGP connections handled by the bgp-speaker. (Config attribute +peer-registry is optional for now to preserve backwards compatibility). +With this configuration, the connection to 192.0.2.1 is initiated by +OpenDaylight but will also be accepted from 192.0.2.1. In case both +connections are being established, only one of them will be preserved +and the other will be dropped. The connection initiated from device with +lower BGP id will be dropped by the registry. Each BGP peer must be +configured in its own ``module`` block. Note, that the name of the +module needs to be unique, so if you are configuring more peers, when +changing the **host**, also change the **name**. + +To configure a peer that only listens for incoming connections and +instruct OpenDaylight not to initiate the connection, add the +initiate-connection attribute to peer’s configuration and set it to +false: + +.. code:: xml + + + prefix:bgp-peer + example-bgp-peer + 192.0.2.1 // IP address or hostname of the speaker + 180 + false // Connection will not be initiated by ODL + ... + + +- **initiate-connection** - if set to false OpenDaylight will not + initiate connection to this peer. Default value is true. + +BGP Application Peer +~~~~~~~~~~~~~~~~~~~~ + +A BGP speaker needs to register all peers that can be connected to it +(meaning if a BGP peer is not configured, the connection with +OpenDaylight won’t be successful). As a first step, configure RIB. Then, +instead of configuring regular peer, configure this application peer, +with its own application RIB. Change the bgp-peer-id, which is your +local BGP ID that will be used in BGP best path selection algorithm. + +.. code:: xml + + + x:bgp-application-peer + example-bgp-peer-app + 10.25.1.9 + + x:rib-instance + example-bgp-rib + + example-app-rib + ... + + +- **bgp-peer-id** - the local BGP identifier (the IP of the VM where + OpenDaylight is deployed), we use this in best path selection + +- **target-rib** - RIB ID of existing RIB where the data should be + transferred + +- **application-rib-id** - RIB ID of local application RIB (all the + routes that you put to OpenDaylight will be displayed here) + +Configuration through RESTCONF +------------------------------ + +Another method to configure BGP is dynamically through RESTCONF. Instead +of restarting Karaf, install another feature, that provides you the +access to *restconf/config/* URLs. + +:: + + feature:install odl-netconf-connector-all + +To check what modules you have currently configured, check following +link: +http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/ + +This URL is also used to POST new configuration. If you want to change +any other configuration that is listed here, make sure you include the +correct namespaces. RESTCONF will tell you if some namespace is wrong. + +To update an existing configuration use **PUT** and give the full path +to the element you wish to update. + +It is vital that you respect the order of steps described in user guide. + +RIB +~~~ + +First, configure the RIB. This module is already present in the +configuration, therefore we change only the parameters we need. In this +case, it’s **bgp-rib-id** and **local-as**. + +**URL:** +*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-rib-impl-cfg:rib-impl/example-bgp-rib* + +**PUT:** + +.. code:: xml + + + x:rib-impl + example-bgp-rib + + x:reconnect-strategy-factory + example-reconnect-strategy-factory + + example-bgp-rib + + x:extensions + global-rib-extensions + + + x:binding-codec-tree-factory + runtime-mapping-singleton + + + x:reconnect-strategy-factory + example-reconnect-strategy-factory + + + x:binding-async-data-broker + pingpong-binding-data-broker + + 64496 + + bgp-dispatcher + global-bgp-dispatcher + + + x:dom-async-data-broker + pingpong-broker + + + bgp-table-type + ipv4-unicast + + + bgp-table-type + ipv6-unicast + + + bgp-table-type + linkstate + + + bgp-table-type + ipv4-flowspec + + + bgp-table-type + ipv6-flowspec + + + bgp-table-type + labeled-unicast + + 192.0.2.2 + + x:bgp-openconfig-provider + openconfig-bgp + + + +Depending on your BGP router, you might need to switch from linkstate +attribute type 99 to 29. Check with your router vendor. Change the field +iana-linkstate-attribute-type to true if your router supports type 29. +You can do that with the following RESTCONF operation: + +**URL:** +*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-linkstate-cfg:bgp-linkstate/bgp-linkstate* + +**PUT:** + +.. code:: xml + + + x:bgp-linkstate + bgp-linkstate + true + + +BGP Peer +~~~~~~~~ + +We also need to add a new module to configuration (bgp-peer). In this +case, the whole module needs to be configured. Please change values +**host**, **holdtimer** and **peer-role** (if necessary). + +**URL:** +*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules* + +**POST:** + +.. code:: xml + + + x:bgp-peer + example-bgp-peer + 192.0.2.1 + 180 + ibgp + + x:rib-instance + example-bgp-rib + + + x:bgp-peer-registry + global-bgp-peer-registry + + + x:bgp-table-type + ipv4-unicast + + + x:bgp-table-type + ipv6-unicast + + + x:bgp-table-type + linkstate + + + x:bgp-table-type + ipv4-flowspec + + + x:bgp-table-type + ipv6-flowspec + + + x:bgp-table-type + labeled-unicast + + + +This is all necessary information that you need to get ODL connect to +your speaker. + +BGP Application Peer +~~~~~~~~~~~~~~~~~~~~ + +Change the value **bgp-peer-id** which is your local BGP ID that will be +used in BGP Best Path Selection algorithm. + +**URL:** +*http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules* + +**POST:** + +.. code:: xml + + + x:bgp-application-peer + example-bgp-peer-app + 10.25.1.9 + + x:rib-instance + example-bgp-rib + + example-app-rib + + x:dom-async-data-broker + pingpong-broker + + + +Tutorials +--------- + +Viewing BGP Topology +~~~~~~~~~~~~~~~~~~~~ + +This section summarizes how data from BGP can be viewed through +RESTCONF. Currently it is the only way to view the data. + +Network Topology View +^^^^^^^^^^^^^^^^^^^^^ + +The URL for network topology is: +http://localhost:8181/restconf/operational/network-topology:network-topology/ + +If BGP is configured properly, it should display output similar to: + +.. code:: xml + + + + pcep-topology + + + + + + true + example-ipv4-topology + + + + true + example-linkstate-topology + + + + +BGP topology information as learned from BGP peers are is in three +topologies (if all three are configured): + +- **example-linkstate-topology** - displays links and nodes advertised + through linkstate update messages + + - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology + +- **example-ipv4-topology** - display IPv4 addresses of nodes in the + topology + + - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology + +- **example-ipv6-topology** - display IPv6 addresses of nodes in the + topology + + - http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv6-topology + +Route Information Base (RIB) View +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Another view of BGP data is through **BGP RIBs**, located here: +http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/ + +There are multiple RIBs configured: + +- AdjRibsIn (per Peer) : Adjacency RIBs In, BGP routes as they come + from BGP Peer + +- EffectiveRib (per Peer) : BGP routes after applying Import policies + +- LocRib (per RIB) : Local RIB, BGP routes from all peers + +- AdjRibsOut (per Peer) : BGP routes that will be advertizes, after + applying Export policies + +This is how the empty output looks like, when address families for IPv4 +Unicast, IPv6 Unicast, IPv4 Flowspec, IPv6 Flowspec, IPv4 Labeled +Unicast and Linkstate were configured: + +.. code:: xml + + + + x:ipv6-address-family + x:unicast-subsequent-address-family + + false + + + + + + x:ipv4-address-family + x:unicast-subsequent-address-family + + false + + + + + + x:ipv4-address-family + x:flowspec-subsequent-address-family + + false + + + + + + x:ipv6-address-family + x:flowspec-subsequent-address-family + + false + + + + + + x:ipv4-address-family + x:labeled-unicast-subsequent-address-family + + false + + + + + + x:linkstate-address-family + x:linkstate-subsequent-address-family + + false + + + + + + +You can see details for each AFI by expanding the RESTCONF link: + +- **IPv4 Unicast** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes + +- **IPv6 Unicast** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes + +- **IPv4 Labeled Unicast** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes + +- **IPv4 Flowspec** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes + +- **IPv6 Flowspec** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes + +- **Linkstate** : + http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes + +Populate RIB +~~~~~~~~~~~~ + +If an application peer is configured, you can populate its RIB by making +POST calls to RESTCONF like the following. + +IPv4 Unicast +^^^^^^^^^^^^ + +**Add route:** + +**URL:** +http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ + +- where example-app-rib is your application RIB id (that you specified + in the configuration) and tables specifies AFI and SAFI of the data + that you want to add. + +**Method:** POST + +**Content-Type:** application/xml + +.. code:: xml + + + + 1.1.1.1/32 + + + 199.20.160.41 + + + 0 + + + 100 + + + 41.41.41.41 + + + igp + + + 40.40.40.40 + + + + +The request results in **204 No content**. This is expected. + +**Delete route:** + +**URL:** +`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/ >`__ + +**Method:** DELETE + +IPv6 Unicast +^^^^^^^^^^^^ + +**Add route:** + +**URL:** +http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/ + +**Method:** POST + +**Content-Type:** application/xml + +.. code:: xml + + + 2001:db8:30::3/128 + + + 2001:db8:1::6 + + + + egp + + + + +The request results in **204 No content**. This is expected. + +**Delete route:** + +**URL:** +`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/bgp-inet:ipv6-route/ >`__ + +**Method:** DELETE + +IPv4 Labeled Unicast +^^^^^^^^^^^^^^^^^^^^ + +**Add route:** + +**URL:** +http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes + +**Method:** POST + +**Content-Type:** application/xml + +.. code:: xml + + + label1 + 1.1.1.1/32 + + 123 + + + 456 + + + 342 + + + + 199.20.160.41 + + + igp + + + + 100 + + + + +The request results in **204 No content**. This is expected. + +**Delete route:** + +**URL:** +`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/ >`__ + +**Method:** DELETE + +IPv4 Flowspec +^^^^^^^^^^^^^ + +**Add route:** + +**URL:** +http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes + +**Method:** POST + +**Content-Type:** application/xml + +.. code:: xml + + + flow1 + + 192.168.0.1/32 + + + 10.0.0.1/32 + + + + equals end-of-list + 6 + + + + + equals end-of-list + 80 + + + + + greater-than + 8080 + + + and-bit less-than end-of-list + 8088 + + + + + greater-than end-of-list + 1024 + + + + + equals end-of-list + 0 + + + + + equals end-of-list + 0 + + + + + match end-of-list + 32 + + + + + greater-than + 400 + + + and-bit less-than end-of-list + 500 + + + + + equals end-of-list + 20 + + + + + match end-of-list + first + + + + + igp + + + + 100 + + + .... + + + + +**Flowspec Extended Communities (Actions):** + +.. code:: xml + + + true + + 123 + AAAAAA== + + + + + true + + true + false + + + + + true + + 123 + AAAAew== + + + + + true + + 192.168.0.1 + 12345 + + + + + true + + 64495 + 12345 + + + + + true + + false + + + + + true + + 20 + + + +The request results in **204 No content**. This is expected. + +**Delete route:** + +**URL:** +`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/ >`__ + +**Method:** DELETE + +IPv6 Flowspec +^^^^^^^^^^^^^ + +**Add route:** + +**URL:** +http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes + +**Method:** POST + +**Content-Type:** application/xml + +.. code:: xml + + + flow-v6 + + 2001:db8:30::3/128 + + + 2001:db8:31::3/128 + + + + equals end-of-list + 1 + + + + + + 2001:db8:1::6 + 12345 + + + + igp + + + + 100 + + + + +The request results in **204 No content**. This is expected. + +**Delete route:** + +**URL:** +`http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/ >`__ + +**Method:** DELETE + diff --git a/docs/user-guide/pcep-user-guide.rst b/docs/user-guide/pcep-user-guide.rst new file mode 100644 index 000000000..1a87adcf1 --- /dev/null +++ b/docs/user-guide/pcep-user-guide.rst @@ -0,0 +1,340 @@ +PCEP User Guide +=============== + +Overview +-------- + +The OpenDaylight Karaf distribution comes preconfigured with baseline +PCEP configuration. + +- **32-pcep.xml** (basic PCEP configuration, including session + parameters) + +- **39-pcep-provider.xml** (configuring for PCEP provider) + +Configuring PCEP +---------------- + +The default shipped configuration will start a PCE server on +0.0.0.0:4189. You can change this behavior in **39-pcep-provider.xml**: + +.. code:: xml + + + prefix:pcep-topology-provider + pcep-topology + 192.168.122.55 + 4189 + ... + + +- **listen-address** - adress on which PCE will be started and listen + +- **listen-port** - port on which the address will be started and + listen + +PCEP default configuration is set to conform stateful PCEP extensions: + +- `draft-ietf-pce-stateful-pce-07 `__ + - PCEP Extensions for Stateful PCE + +- `draft-ietf-pce-pce-initiated-lsp-00 `__ + - PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model + +- `draft-ietf-pce-stateful-sync-optimizations-03 `__ + - Optimizations of Label Switched Path State Synchronization + Procedures for a Stateful PCE + +PCEP Segment Routing +~~~~~~~~~~~~~~~~~~~~ + +Conforms +`draft-ietf-pce-segment-routing `__ +- PCEP extension for Segment Routing + +The default configuration file is located in etc/opendaylight/karaf. + +- **33-pcep-segment-routing.xml** - You don’t need to edit this file. + +Tunnel Management +----------------- + +Programming tunnels through PCEP is one of the key features of PCEP +implementation in OpenDaylight. User can create, update and delete +tunnel via RESTCONF calls. Tunnel (LSP - Label Switched Path) arguments +are passed through RESTCONF and generate a PCEP message that is sent to +PCC (which is also specified via RESTCONF call). PCC sends a response +back to OpenDaylight. The response is then interpreted and sent to +RESTCONF, where, in case of success, the new LSP is displayed. + +The PCE Segment Routing Extends draft-ietf-pce-stateful-pce-07 and +draft-ietf-pce-pce-initiated-lsp-00, brings new Segment Routing Explicit +Route Object (SR-ERO) subobject composed of SID (Segment Identifier) +and/or NAI (Node or Adjacency Identifier). Segment Routing path is +carried in the ERO object, as a list of SR-ERO subobjects ordered by +user. The draft redefines format of messages (PCUpd, PCRpt, PCInitiate) +- along with common header, they can hold SPR, LSP and SR-ERO +(containing only SR-ERO subobjects) objects. + +Creating LSP +~~~~~~~~~~~~ + +An LSP in PCEP can be created in one or two steps. Making an add-lsp +operation will trigger a PcInitiate message to PCC. + +**URL:** +http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp + +**Method:** POST + +**Content-Type:** application/xml + +**Body:** + +**PCE Active Stateful:** + +.. code:: xml + + + pcc://43.43.43.43 + update-tunel + + + true + true + + + + 43.43.43.43 + 39.39.39.39 + + + + + false + 201.20.160.40/32 + + + false + 195.20.160.39/32 + + + false + 39.39.39.39/32 + + + + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +**PCE Segment Routing:** + +.. code:: xml + + + pcc://43.43.43.43 + update-tunnel + + + true + true + + + + 43.43.43.43 + 39.39.39.39 + + + + 1 + + + + false + ipv4-node-id + true + 12 + 39.39.39.39 + + + + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +Updating LSP +~~~~~~~~~~~~ + +Making an update-lsp operation will trigger a PCUpd message to PCC. +Updating can be used to change or add additional information to the LSP. + +You can only successfully update an LSP if you own the delegation. You +automatically own the delegation, if you’ve created the LSP. You don’t +own it, if another PCE created this LSP. In this case PCC is only +reporting this LSP for you, as read-only (you’ll see +``false``). However OpenDaylight won’t restrict you +from trying to modify the LSP, but you will be stopped by receiving a +PCErr message from PCC. + +To revoke delegation, don’t forget to set ```` to true. + +**URL:** +http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp + +**Method:** POST + +**Content-Type:** application/xml + +**Body:** + +**PCE Active Stateful:** + +.. code:: xml + + + pcc://43.43.43.43 + update-tunel + + + true + true + + + + false + 200.20.160.41/32 + + + false + 196.20.160.39/32 + + + false + 39.39.39.39/32 + + + + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +**PCE Segment Routing:** + +.. code:: xml + + + pcc://43.43.43.43 + update-tunnel + + + true + true + + + 1 + + + + false + ipv4-node-id + true + 11 + 200.20.160.41 + + + false + ipv4-node-id + true + 12 + 39.39.39.39 + + + + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +Removing LSP +~~~~~~~~~~~~ + +Removing LSP from PCC is done via following RESTCONF URL. Making a +remove-lsp operation will trigger a PCInitiate message to PCC, with +remove-flag in SRP set to true. + +You can only successfully remove an LSP if you own the delegation. You +automatically own the delegation, if you’ve created the LSP. You don’t +own it, if another PCE created this LSP. In this case PCC is only +reporting this LSP for you, as read-only (you’ll see +``false``). However OpenDaylight won’t restrict you +from trying to remove the LSP, but you will be stopped by receiving a +PCErr message from PCC. + +To revoke delegation, don’t forget to set ```` to true. + +**URL:** +http://localhost:8181/restconf/operations/network-topology-pcep:remove-lsp + +**Method:** POST + +**Content-Type:** application/xml + +**Body:** + +.. code:: xml + + + pcc://43.43.43.43 + update-tunel + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +PCE-triggered Initial Synchronization +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Making an trigger-sync operation will trigger a PCUpd message to PCC +with PLSP-ID = 0 and SYNC = 1 in order to trigger the LSP-DB +synchronization process. + +**URL:** +http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync + +**Method:** POST + +**Content-Type:** application/xml + +**Body:** + +.. code:: xml + + + pcc://43.43.43.43 + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +PCE-triggered Re-synchronization +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Making an trigger-resync operation will trigger a PCUpd message to PCC. +The PCE can choose to re-synchronize its entire LSP database or a single +LSP. + +**URL:** +http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync + +**Method:** POST + +**Content-Type:** application/xml + +**Body:** + +.. code:: xml + + + pcc://43.43.43.43 + re-sync-lsp + /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] + + +PCE-triggered LSP database Re-synchronization +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +PCE-triggered LSP database Re-synchronization works same as in +PCE-triggered Initial Synchronization. + diff --git a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bgp-all-user.adoc b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bgp-all-user.adoc index e1e208489..4640c2071 100644 --- a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bgp-all-user.adoc +++ b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bgp-all-user.adoc @@ -1,911 +1,3 @@ == BGP User Guide == -=== Configuring BGP === - -The OpenDaylight Karaf distribution comes pre-configured with a baseline BGP -configuration. You can find it in the `etc/opendaylight/karaf` directory and it -consists of two files: - -`31-bgp.xml`:: defines the basic parser and RIB support -`41-bgp-example.xml`:: contains a sample configuration which needs to be - customized to your deployment) - -The next sections will describe how to configure BGP manually or using RESTCONF. - -==== RIB ==== - -The configuration of the Routing Information Base (RIB) is specified using a block in the `41-bgp-example.xml` file. - -[source,xml] ----- - - prefix:rib-impl - example-bgp-rib - example-bgp-rib - 64496 - 192.0.2.2 - 192.0.2.3 - ... - ----- - -- *type* - should always be set to `prefix:rib-impl` -- *name* and *rib-id* - BGP RIB Identifier, you can specify multiple BGP RIBs by -having multiple the above `module` blocks. Each such RIB must have a unique rib-id and name. -- *local-as* - the local AS number (where OpenDaylight is deployed), we use this in best path selection -- *bgp-id* - the local BGP identifier (the IP of the VM where OpenDaylight is deployed), -we use this in best path selection. -- *cluster-id* - cluster identifier, optional, if not specified, BGP Identifier will be used - -Depending on your BGP router, you might need to switch from -linkstate attribute type 99 to 29. Check with your router vendor. Change the -field iana-linkstate-attribute-type to true if your router supports type 29. -This snippet is located in `31-bgp.xml` file. - -[source,xml] ----- - - prefix:bgp-linkstate - bgp-linkstate - true - ----- - -- *iana-linkstate-attribute-type* - IANA has issued an early allocation for the -BGP linkstate path attribute (=29). To preserve he old value (=99) set this to -to false; to use IANA assigned type set the value to true or remove it as it's true by default. - -==== BGP Peer ==== - -The initial configuration is written so that it will be ignored to prevent the -client from starting with default configuration. Therefore the first step is to -uncomment the module containing bgp-peer. - -[source,xml] ----- - - prefix:bgp-peer - example-bgp-peer - 192.0.2.1 - 180 - ibgp - - prefix:rib-instance - example-bgp-rib - - ... - ----- - -- *name* - BGP Peer name, in this configuration file you specify multiple BGP Peers by replicating the above `module` block. Each peers must have a unique name. -- *host* - IP address or hostname of BGP speaker where OpenDaylight should connect to the peer -- *holdtimer* - hold time in seconds -- *peer-role* - If peer role is not present, default value "ibgp" will be used (other allowed values are "ebgp" and "rr-client"). This field is case-sensitive. -- *rib* - BGP RIB identifier - -==== Configure Connection Attributes (Optional) ==== - -[source,xml] ----- - - prefix:timed-reconnect-strategy - example-reconnect-strategy - 1000 - 180000 - 2.00 - 5000 - - netty:netty-event-executor - global-event-executor - - ----- - -- *min-sleep* - minimum sleep time (miliseconds) in between reconnect tries -- *max-sleep* - maximum sleep time (miliseconds) in between reconnect tries -- *sleep-factor* - power factor of the sleep time between reconnect tries, i.e., the previous sleep time will be multiplied by this number to determine the next sleep time, but never exceed *max-sleep* -- *connect-time* - how long BGP should wait (miliseconds) for the TCP connect -attempt, overrides default connection timeout dictated by TCP. - - -==== BGP Speaker Configuration ==== - -The previous entries described configuration of a BGP connections initiated by -OpenDaylight. OpenDaylight can also accept incoming BGP connections. - -The configuration of BGP speaker is located in: `41-bgp-example.xml`: - -[source,xml] ----- - - prefix:bgp-peer-acceptor - bgp-peer-server - - - - - - ... - - - prefix:bgp-peer-registry - global-bgp-peer-registry - - ----- - -- Changing binding address: Uncomment tag binding-address and change the address to e.g. _127.0.0.1_. The default binding address is _0.0.0.0_. -- Changing binding port: Uncomment tag binding-port and change the port to e.g. - _1790_. The default binding port is _179_ as specified in link:http://tools.ietf.org/html/rfc4271[RFC 4271]. - -==== Incomming BGP Connections ==== - -*The BGP speaker drops all BGP connections from unknown BGP peers.* The decision is -made in component bgp-peer-registry that is injected into the speaker (The -registry is configured in `31-bgp.xml`). - -To add a BGP Peer configuration into the registry, it is necessary to configure -regular BGP peer just like in example in `41-bgp-example.xml`. Notice that the -BGP peer depends on the same bgp-peer-registry as bgp-speaker: - -[source,xml] ----- - - prefix:bgp-peer - example-bgp-peer - 192.0.2.1 - ... - - prefix:bgp-peer-registry - global-bgp-peer-registry - - ... - ----- - -The BGP peer registers itself into the registry, which allows incoming BGP -connections handled by the bgp-speaker. (Config attribute peer-registry is -optional for now to preserve backwards compatibility). With this configuration, -the connection to 192.0.2.1 is initiated by OpenDaylight but will also be accepted from -192.0.2.1. In case both connections are being established, only one of them -will be preserved and the other will be dropped. The connection initiated from -device with lower BGP id will be dropped by the registry. Each BGP peer must -be configured in its own `module` block. Note, that the name of the module needs to be -unique, so if you are configuring more peers, when changing the *host*, also change -the *name*. - -To configure a peer that only listens for incoming connections and instruct -OpenDaylight not to initiate the connection, add the initiate-connection attribute -to peer's configuration and set it to false: - -[source,xml] ----- - - prefix:bgp-peer - example-bgp-peer - 192.0.2.1 // IP address or hostname of the speaker - 180 - false // Connection will not be initiated by ODL - ... - ----- - -- *initiate-connection* - if set to false OpenDaylight will not initiate connection to this peer. Default value is true. - -==== BGP Application Peer ==== - -A BGP speaker needs to register all peers that can be connected to it (meaning if -a BGP peer is not configured, the connection with OpenDaylight won't be -successful). As a first step, configure RIB. Then, instead of configuring -regular peer, configure this application peer, with its own application RIB. -Change the bgp-peer-id, which is your local BGP ID that will be -used in BGP best path selection algorithm. - -[source,xml] ----- - - x:bgp-application-peer - example-bgp-peer-app - 10.25.1.9 - - x:rib-instance - example-bgp-rib - - example-app-rib - ... - ----- - -- *bgp-peer-id* - the local BGP identifier (the IP of the VM where OpenDaylight is deployed), we use this in best path selection -- *target-rib* - RIB ID of existing RIB where the data should be transferred -- *application-rib-id* - RIB ID of local application RIB (all the routes that you put to OpenDaylight will be displayed here) - -//TODO: internal link to Populate RIB -//To populate RIB use - -//TODO: internal jump to section? -//In order to get routes advertised to other peers, you have to also configure the peers, as described in section BGP Peer - -=== Configuration through RESTCONF === - -Another method to configure BGP is dynamically through RESTCONF. Instead of -restarting Karaf, install another feature, that provides you the access to -'restconf/config/' URLs. - - feature:install odl-netconf-connector-all - -To check what modules you have currently configured, check following link: -http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/ - -This URL is also used to POST new configuration. If you want to change any -other configuration that is listed here, make sure you include the correct -namespaces. RESTCONF will tell you if some namespace is wrong. - -To update an existing configuration use *PUT* and give the full path to the element you wish to update. - -It is vital that you respect the order of steps described in user guide. - -==== RIB ==== - -First, configure the RIB. This module is already present in the configuration, -therefore we change only the parameters we need. In this case, it's -*bgp-rib-id* and *local-as*. - -*URL:* -_http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-rib-impl-cfg:rib-impl/example-bgp-rib_ - -*PUT:* -[source,xml] ----- - - x:rib-impl - example-bgp-rib - - x:reconnect-strategy-factory - example-reconnect-strategy-factory - - example-bgp-rib - - x:extensions - global-rib-extensions - - - x:binding-codec-tree-factory - runtime-mapping-singleton - - - x:reconnect-strategy-factory - example-reconnect-strategy-factory - - - x:binding-async-data-broker - pingpong-binding-data-broker - - 64496 - - bgp-dispatcher - global-bgp-dispatcher - - - x:dom-async-data-broker - pingpong-broker - - - bgp-table-type - ipv4-unicast - - - bgp-table-type - ipv6-unicast - - - bgp-table-type - linkstate - - - bgp-table-type - ipv4-flowspec - - - bgp-table-type - ipv6-flowspec - - - bgp-table-type - labeled-unicast - - 192.0.2.2 - - x:bgp-openconfig-provider - openconfig-bgp - - ----- - -Depending on your BGP router, you might need to switch from -linkstate attribute type 99 to 29. Check with your router vendor. Change the -field iana-linkstate-attribute-type to true if your router supports type 29. -You can do that with the following RESTCONF operation: - -*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/module/odl-bgp-linkstate-cfg:bgp-linkstate/bgp-linkstate_ - -*PUT:* -[source,xml] ----- - - x:bgp-linkstate - bgp-linkstate - true - ----- - -==== BGP Peer ==== - -We also need to add a new module to configuration (bgp-peer). In this case, the -whole module needs to be configured. Please change values *host*, *holdtimer* -and *peer-role* (if necessary). - -*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules_ - -*POST:* - -[source,xml] ----- - - x:bgp-peer - example-bgp-peer - 192.0.2.1 - 180 - ibgp - - x:rib-instance - example-bgp-rib - - - x:bgp-peer-registry - global-bgp-peer-registry - - - x:bgp-table-type - ipv4-unicast - - - x:bgp-table-type - ipv6-unicast - - - x:bgp-table-type - linkstate - - - x:bgp-table-type - ipv4-flowspec - - - x:bgp-table-type - ipv6-flowspec - - - x:bgp-table-type - labeled-unicast - - ----- - -This is all necessary information that you need to get ODL connect to your speaker. - -==== BGP Application Peer ==== - -Change the value *bgp-peer-id* which is your local BGP ID that will be used in -BGP Best Path Selection algorithm. - -*URL:* _http://127.0.0.1:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules_ - -*POST:* -[source,xml] ----- - - x:bgp-application-peer - example-bgp-peer-app - 10.25.1.9 - - x:rib-instance - example-bgp-rib - - example-app-rib - - x:dom-async-data-broker - pingpong-broker - - ----- - -=== Tutorials === - -==== Viewing BGP Topology ==== - -This section summarizes how data from BGP can be viewed through RESTCONF. Currently it is the only way to view the data. - -===== Network Topology View ===== - -The URL for network topology is: http://localhost:8181/restconf/operational/network-topology:network-topology/ - -If BGP is configured properly, it should display output similar to: - -[source,xml] ----- - - - pcep-topology - - - - - - true - example-ipv4-topology - - - - true - example-linkstate-topology - - - ----- - -BGP topology information as learned from BGP peers are is in three topologies (if all three are configured): - -* *example-linkstate-topology* - displays links and nodes advertised through linkstate update messages - -** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology - -* *example-ipv4-topology* - display IPv4 addresses of nodes in the topology - -** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology - -* *example-ipv6-topology* - display IPv6 addresses of nodes in the topology - -** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv6-topology - -===== Route Information Base (RIB) View ===== - -Another view of BGP data is through *BGP RIBs*, located here: http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/ - -There are multiple RIBs configured: - -- AdjRibsIn (per Peer) : Adjacency RIBs In, BGP routes as they come from BGP Peer -- EffectiveRib (per Peer) : BGP routes after applying Import policies -- LocRib (per RIB) : Local RIB, BGP routes from all peers -- AdjRibsOut (per Peer) : BGP routes that will be advertizes, after applying Export policies - -This is how the empty output looks like, when address families for IPv4 Unicast, IPv6 Unicast, IPv4 Flowspec, IPv6 Flowspec, IPv4 Labeled Unicast and Linkstate were configured: - -[source,xml] ----- - - - x:ipv6-address-family - x:unicast-subsequent-address-family - - false - - - - - - x:ipv4-address-family - x:unicast-subsequent-address-family - - false - - - - - - x:ipv4-address-family - x:flowspec-subsequent-address-family - - false - - - - - - x:ipv6-address-family - x:flowspec-subsequent-address-family - - false - - - - - - x:ipv4-address-family - x:labeled-unicast-subsequent-address-family - - false - - - - - - x:linkstate-address-family - x:linkstate-subsequent-address-family - - false - - - - - ----- - -You can see details for each AFI by expanding the RESTCONF link: - -* *IPv4 Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/ipv4-routes - -* *IPv6 Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/ipv6-routes - -* *IPv4 Labeled Unicast* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes - -* *IPv4 Flowspec* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes - -* *IPv6 Flowspec* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes - -* *Linkstate* : http://localhost:8181/restconf/operational/bgp-rib:bgp-rib/rib/example-bgp-rib/loc-rib/tables/bgp-linkstate:linkstate-address-family/bgp-linkstate:linkstate-subsequent-address-family/linkstate-routes - -==== Populate RIB ==== - -If an application peer is configured, you can populate its RIB by making POST calls to RESTCONF like the following. - -===== IPv4 Unicast ===== - -*Add route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/ - -- where example-app-rib is your application RIB id (that you specified in the configuration) and tables specifies AFI and SAFI of the data that you want to add. - -*Method:* POST - -*Content-Type:* application/xml - -[source,xml] ----- - - - 1.1.1.1/32 - - - 199.20.160.41 - - - 0 - - - 100 - - - 41.41.41.41 - - - igp - - - 40.40.40.40 - - - ----- - -The request results in *204 No content*. This is expected. - -*Delete route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv4-routes/bgp-inet:ipv4-route/ - -*Method:* DELETE - -===== IPv6 Unicast ===== - -*Add route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/ - -*Method:* POST - -*Content-Type:* application/xml - -[source,xml] ----- - - 2001:db8:30::3/128 - - - 2001:db8:1::6 - - - - egp - - - ----- - -The request results in *204 No content*. This is expected. - -*Delete route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-types:unicast-subsequent-address-family/bgp-inet:ipv6-routes/bgp-inet:ipv6-route/ - -*Method:* DELETE - -===== IPv4 Labeled Unicast ===== - -*Add route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes - -*Method:* POST - -*Content-Type:* application/xml - -[source,xml] ----- - - label1 - 1.1.1.1/32 - - 123 - - - 456 - - - 342 - - - - 199.20.160.41 - - - igp - - - - 100 - - - ----- - -The request results in *204 No content*. This is expected. - -*Delete route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-labeled-unicast:labeled-unicast-subsequent-address-family/bgp-labeled-unicast:labeled-unicast-routes/bgp-labeled-unicast:labeled-unicast-route/ - -*Method:* DELETE - -===== IPv4 Flowspec ===== - -*Add route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes - -*Method:* POST - -*Content-Type:* application/xml - -[source,xml] ----- - - flow1 - - 192.168.0.1/32 - - - 10.0.0.1/32 - - - - equals end-of-list - 6 - - - - - equals end-of-list - 80 - - - - - greater-than - 8080 - - - and-bit less-than end-of-list - 8088 - - - - - greater-than end-of-list - 1024 - - - - - equals end-of-list - 0 - - - - - equals end-of-list - 0 - - - - - match end-of-list - 32 - - - - - greater-than - 400 - - - and-bit less-than end-of-list - 500 - - - - - equals end-of-list - 20 - - - - - match end-of-list - first - - - - - igp - - - - 100 - - - .... - - - ----- - -*Flowspec Extended Communities (Actions):* - -[source,xml] ----- - - true - - 123 - AAAAAA== - - - - - true - - true - false - - - - - true - - 123 - AAAAew== - - - - - true - - 192.168.0.1 - 12345 - - - - - true - - 64495 - 12345 - - - - - true - - false - - - - - true - - 20 - - ----- - -The request results in *204 No content*. This is expected. - -*Delete route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv4-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-routes/bgp-flowspec:flowspec-route/ - -*Method:* DELETE - -===== IPv6 Flowspec ===== - -*Add route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes - -*Method:* POST - -*Content-Type:* application/xml - -[source,xml] ----- - - flow-v6 - - 2001:db8:30::3/128 - - - 2001:db8:31::3/128 - - - - equals end-of-list - 1 - - - - - - 2001:db8:1::6 - 12345 - - - - igp - - - - 100 - - - ----- - -The request results in *204 No content*. This is expected. - -*Delete route:* - -*URL:* http://localhost:8181/restconf/config/bgp-rib:application-rib/example-app-rib/tables/bgp-types:ipv6-address-family/bgp-flowspec:flowspec-subsequent-address-family/bgp-flowspec:flowspec-ipv6-routes/bgp-flowspec:flowspec-route/ - -*Method:* DELETE \ No newline at end of file +This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-user-guide.html diff --git a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bmp-user.adoc b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bmp-user.adoc index 6290bf782..44eb3f305 100644 --- a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bmp-user.adoc +++ b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-bmp-user.adoc @@ -1,135 +1,3 @@ == BGP Monitoring Protocol User Guide == -=== Overview === - -The OpenDaylight Karaf distribution comes preconfigured with baseline BMP configuration. - -- *32-bmp.xml* (initial configuration for BMP messages handler service provider and BMP client/server dispatcher settings) -- *42-bmp-example.xml* (sample initial configuration for the BMP Monitoring Station application) - -=== Configuring BMP === - -==== Server Binding ==== -The default shipped configuration will start a BMP server on 0.0.0.0:12345.You can change this behavior in *42-bmp-example.xml*: - -[source,xml] ----- - - prefix:bmp-monitor-impl - example-bmp-monitor - - 12345 - ... - ----- - -- *binding-address* - adress on which BMP will be started and listen; to change value, uncomment then line first -- *binding-port* - port on which the address will be started and listen - -Multiple instances of the BMP monitoring station (*bmp-monitor-impl* module) can be created. However, each instance must have a unique pair of *binding-address* and *binding-port* - -==== Active mode ==== -OpenDaylight's BMP might be configured to act as an active party of the connection (ODL BMP < = > Monitored router). To enable this functionality, -configure monitored-router with mandatory parameters: - -* address (must be unique for each configured "monitored-router"), -* port, -* active. - -See following example from 42-bmp-example.xml: - -[source,xml] ----- - -
192.0.2.2
- 1234 - true - ----- - -=== Configuration through RESTCONF === - -==== Server Binding ==== - -*URL:* -_http://:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor_ - -*Content-Type:* -application/xml - -*Method:* -PUT - -*Body:* -[source,xml] ----- - - example-bmp-monitor - x:bmp-monitor-impl - - bmp-dispatcher - global-bmp-dispatcher - - - x:binding-codec-tree-factory - runtime-mapping-singleton - - - x:extensions - global-rib-extensions - - 0.0.0.0 - - x:dom-async-data-broker - pingpong-broker - - 12345 - ----- - -* change values for *binding-address* and/or *binding-port* - -==== Active mode ==== - -*URL:* -_http://:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/controller-config/yang-ext:mount/config:modules/config:module/odl-bmp-impl-cfg:bmp-monitor-impl/example-bmp-monitor_ - -*Content-Type:* -application/xml - -*Method:* -PUT - -*Body:* -[source,xml] ----- - - example-bmp-monitor - x:bmp-monitor-impl - - bmp-dispatcher - global-bmp-dispatcher - - - x:binding-codec-tree-factory - runtime-mapping-singleton - - - x:extensions - global-rib-extensions - - 0.0.0.0 - - x:dom-async-data-broker - pingpong-broker - - 12345 - -
127.0.0.1
- 1234 - true - - ----- - -* change values for *address* and *port* +This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/bgp-monitoring-protocol-user-guide.html diff --git a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-pcep-all-user.adoc b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-pcep-all-user.adoc index c1b36089e..503cb7de3 100644 --- a/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-pcep-all-user.adoc +++ b/manuals/user-guide/src/main/asciidoc/bgpcep/odl-bgpcep-pcep-all-user.adoc @@ -1,281 +1,3 @@ == PCEP User Guide == -=== Overview === - -The OpenDaylight Karaf distribution comes preconfigured with baseline PCEP configuration. - -- *32-pcep.xml* (basic PCEP configuration, including session parameters) -- *39-pcep-provider.xml* (configuring for PCEP provider) - -=== Configuring PCEP === - -The default shipped configuration will start a PCE server on 0.0.0.0:4189. You can change this behavior in *39-pcep-provider.xml*: - -[source,xml] ----- - - prefix:pcep-topology-provider - pcep-topology - 192.168.122.55 - 4189 -... - ----- - -- *listen-address* - adress on which PCE will be started and listen -- *listen-port* - port on which the address will be started and listen - -PCEP default configuration is set to conform stateful PCEP extensions: - -- http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-07[draft-ietf-pce-stateful-pce-07] - PCEP Extensions for Stateful PCE -- https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00[draft-ietf-pce-pce-initiated-lsp-00] - PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model -- https://tools.ietf.org/html/draft-ietf-pce-stateful-sync-optimizations-03[draft-ietf-pce-stateful-sync-optimizations-03] - Optimizations of Label Switched Path State -Synchronization Procedures for a Stateful PCE - -==== PCEP Segment Routing ==== - -Conforms link:http://tools.ietf.org/html/draft-ietf-pce-segment-routing-01[draft-ietf-pce-segment-routing] - PCEP extension for Segment Routing - -The default configuration file is located in etc/opendaylight/karaf. - -- *33-pcep-segment-routing.xml* - You don't need to edit this file. - -=== Tunnel Management === - -Programming tunnels through PCEP is one of the key features of PCEP implementation in OpenDaylight. -User can create, update and delete tunnel via RESTCONF calls. -Tunnel (LSP - Label Switched Path) arguments are passed through RESTCONF and generate a PCEP message that is sent to PCC (which is also specified via RESTCONF call). -PCC sends a response back to OpenDaylight. The response is then interpreted and sent to RESTCONF, where, in case of success, the new LSP is displayed. - -The PCE Segment Routing Extends draft-ietf-pce-stateful-pce-07 and draft-ietf-pce-pce-initiated-lsp-00, brings new Segment Routing Explicit Route Object (SR-ERO) subobject composed of SID (Segment Identifier) -and/or NAI (Node or Adjacency Identifier). Segment Routing path is carried in the ERO object, as a list of SR-ERO subobjects ordered by user. -The draft redefines format of messages (PCUpd, PCRpt, PCInitiate) - along with common header, they can hold SPR, LSP and SR-ERO (containing only SR-ERO subobjects) objects. - -==== Creating LSP ==== -An LSP in PCEP can be created in one or two steps. Making an add-lsp operation will trigger a PcInitiate message to PCC. - -*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:add-lsp - -*Method:* POST - -*Content-Type:* application/xml - -*Body:* - -*PCE Active Stateful:* -[source,xml] ----- - - pcc://43.43.43.43 - update-tunel - - - true - true - - - - 43.43.43.43 - 39.39.39.39 - - - - - false - 201.20.160.40/32 - - - false - 195.20.160.39/32 - - - false - 39.39.39.39/32 - - - - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -*PCE Segment Routing:* -[source,xml] ----- - - pcc://43.43.43.43 - update-tunnel - - - true - true - - - - 43.43.43.43 - 39.39.39.39 - - - - 1 - - - - false - ipv4-node-id - true - 12 - 39.39.39.39 - - - - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -==== Updating LSP ==== -Making an update-lsp operation will trigger a PCUpd message to PCC. Updating can be used to change or add additional information to the LSP. - -You can only successfully update an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP. -You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see +false+). -However OpenDaylight won't restrict you from trying to modify the LSP, but you will be stopped by receiving a PCErr message from PCC. - -To revoke delegation, don't forget to set ++ to true. - -*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:update-lsp - -*Method:* POST - -*Content-Type:* application/xml - -*Body:* - -*PCE Active Stateful:* -[source,xml] ----- - - pcc://43.43.43.43 - update-tunel - - - true - true - - - - false - 200.20.160.41/32 - - - false - 196.20.160.39/32 - - - false - 39.39.39.39/32 - - - - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -*PCE Segment Routing:* -[source,xml] ----- - - pcc://43.43.43.43 - update-tunnel - - - true - true - - - 1 - - - - false - ipv4-node-id - true - 11 - 200.20.160.41 - - - false - ipv4-node-id - true - 12 - 39.39.39.39 - - - - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -==== Removing LSP ==== -Removing LSP from PCC is done via following RESTCONF URL. Making a remove-lsp operation will trigger a PCInitiate message to PCC, with remove-flag in SRP set to true. - -You can only successfully remove an LSP if you own the delegation. You automatically own the delegation, if you've created the LSP. -You don't own it, if another PCE created this LSP. In this case PCC is only reporting this LSP for you, as read-only (you'll see +false+). -However OpenDaylight won't restrict you from trying to remove the LSP, but you will be stopped by receiving a PCErr message from PCC. - -To revoke delegation, don't forget to set ++ to true. - -*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:remove-lsp - -*Method:* POST - -*Content-Type:* application/xml - -*Body:* -[source,xml] ----- - - pcc://43.43.43.43 - update-tunel - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -==== PCE-triggered Initial Synchronization ==== -Making an trigger-sync operation will trigger a PCUpd message to PCC with PLSP-ID = 0 and SYNC = 1 in order to trigger the LSP-DB synchronization process. - -*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync - -*Method:* POST - -*Content-Type:* application/xml - -*Body:* -[source,xml] ----- - - pcc://43.43.43.43 - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -==== PCE-triggered Re-synchronization ==== -Making an trigger-resync operation will trigger a PCUpd message to PCC. The PCE can choose to re-synchronize its entire LSP database or a single LSP. - -*URL:* http://localhost:8181/restconf/operations/network-topology-pcep:trigger-sync - -*Method:* POST - -*Content-Type:* application/xml - -*Body:* -[source,xml] ----- - - pcc://43.43.43.43 - re-sync-lsp - /topo:network-topology/topo:topology[topo:topology-id="pcep-topology"] - ----- - -==== PCE-triggered LSP database Re-synchronization ==== - -PCE-triggered LSP database Re-synchronization works same as in PCE-triggered Initial Synchronization. \ No newline at end of file +This content has been migrated to: http://docs.opendaylight.org/en/stable-boron/user-guide/pcep-user-guide.html -- 2.36.6