== BGP Developer Guide
=== Overview
-This section provides an overview of *feature odl-bgpcep-bgp-all* . This
+This section provides an overview of the `odl-bgpcep-bgp-all` Karaf feature. This
feature will install everything needed for BGP (Border Gateway Protocol)
from establishing the connection, storing the data in RIBs (Route Information
Base) and displaying data in network-topology overview.
Each feature represents a module in the BGPCEP codebase. The following diagram
illustrates how the features are related.
-image::bgpcep/bgp-dependency-tree.png[height="450px", width="550px",title="BGP Dependency Tree"]
+image::bgpcep/bgp-dependency-tree.png[width="500px",title="BGP Dependency Tree"]
=== Key APIs and Interfaces
==== BGP concepts
This module contains the base BGP concepts contained in
-http://tools.ietf.org/html/rfc4271[RFC4271],
-http://tools.ietf.org/html/rfc4760[RFC4760],
-http://tools.ietf.org/html/rfc4456[RFC4456],
-http://tools.ietf.org/html/rfc1997[RFC1997] and
-http://tools.ietf.org/html/rfc4360[RFC4360].
+http://tools.ietf.org/html/rfc4271[RFC 4271],
+http://tools.ietf.org/html/rfc4760[RFC 4760],
+http://tools.ietf.org/html/rfc4456[RFC 4456],
+http://tools.ietf.org/html/rfc1997[RFC 1997] and
+http://tools.ietf.org/html/rfc4360[RFC 4360].
-All the concepts are described in one yang model :
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/lithium[bgp-types.yang]
-.
+All the concepts are described in one yang model:
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/yang/bgp-types.yang;hb=refs/heads/stable/beryllium[bgp-types.yang].
Outside generated classes, there is just one class
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/lithium[NextHopUtil]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/concepts/src/main/java/org/opendaylight/bgp/concepts/NextHopUtil.java;hb=refs/heads/stable/beryllium[NextHopUtil]
that contains methods for serializing and parsing NextHop.
==== BGP parser
Base BGP parser includes messages and attributes from
-http://tools.ietf.org/html/rfc4271[RFC4271],
-http://tools.ietf.org/html/rfc4760[RFC4760],
-http://tools.ietf.org/html/rfc1997[RFC1997] and
-http://tools.ietf.org/html/rfc4360[RFC4360].
+http://tools.ietf.org/html/rfc4271[RFC 4271],
+http://tools.ietf.org/html/rfc4760[RFC 4760],
+http://tools.ietf.org/html/rfc1997[RFC 1997] and
+http://tools.ietf.org/html/rfc4360[RFC 4360].
_API_ module defines BGP messages in YANG.
_IMPL_ module contains actual parsers and serializers for BGP messages
and
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/lithium[Activator]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-impl/src/main/java/org/opendaylight/protocol/bgp/parser/impl/BGPActivator.java;hb=refs/heads/stable/beryllium[Activator]
class
_SPI_ module contains helper classes needed for registering parsers into
===== Registration
-As mentioned before, all parsers and serializers need to be registered
+All parsers and serializers need to be registered
into the _Extension provider_. This _Extension provider_ is configured in
-initial configuration of the parser-spi module (_31-bgp.xml_).
+initial configuration of the parser-spi module (`31-bgp.xml`).
[source,xml]
----
The configuration of bgp-parser-spi specifies one implementation of
_Extension provider_ that will take care of registering mentioned parser
extensions:
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/lithium[SimpleBGPExtensionProviderContext].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi/pojo/SimpleBGPExtensionProviderContext.java;hb=refs/heads/stable/beryllium[SimpleBGPExtensionProviderContext].
All registries are implemented in package
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/lithium[bgp-parser-spi].
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=bgp/parser-spi/src/main/java/org/opendaylight/protocol/bgp/parser/spi;hb=refs/heads/stable/beryllium[bgp-parser-spi].
===== Serializing
-The serializing of BGP elements is mostly done in the same way as in PCEP, the only
-exception is the serialization of path attributes, that is described
+The serializing of BGP elements is mostly done in the same way as in <<_pcep_developer_guide,PCEP>>, the only
+exception is the serialization of path attributes, which is described
here. Path attributes are different from any other BGP element, as
path attributes don't implement one common interface, but this
interface contains getters for individual path attributes (this
go through the registrations and offer this object to the each
registered parser. This way the object will be passed also to
serializers unknown to module bgp-parser, for example to
-LinkstateAttributeParser. RFC4271 recommends ordering path attributes,
+LinkstateAttributeParser. RFC 4271 recommends ordering path attributes,
hence the serializers are ordered in a list as they are registered in
the _Activator_. In other words, this is the only case, where
registration ordering matters.
-image::bgpcep/PathAttributesSerialization.png[height="450px", width="550px",title="PathAttributesSerialization"]
+image::bgpcep/PathAttributesSerialization.png[width="500px",title="PathAttributesSerialization"]
_serialize()_ method in each Path Attribute parser contains check for
presence of its attribute in the PathAttributes object, which simply
=== BGP RIB
-The BGP RIB module can be divided into two semantic parts:
+The BGP RIB module can be divided into two parts:
+
* BGP listener and speaker session handling
* RIB handling.
==== Session handling
-_31-bgp.xml_ defines only bgp-dispatcher and the parser it should be
+`31-bgp.xml` defines only bgp-dispatcher and the parser it should be
using (global-bgp-extensions).
[source,xml]
----
- <module>
+<module>
<type>prefix:bgp-dispatcher-impl</type>
<name>global-bgp-dispatcher</name>
<bgp-extensions>
<type>netty:netty-threadgroup</type>
<name>global-worker-group</name>
</worker-group>
- </module>
+</module>
----
For user configuration of BGP, check User Guide.
Synchronization is a phase, where upon connection, a BGP speaker sends all
available data about topology to its new client. After the whole
-topology has been advertized, the synchronization is over. For the
+topology has been advertised, the synchronization is over. For the
listener, the synchronization is over when the RIB receives End-of-RIB
(EOR) messages. There is a special EOR message for each AFI (Address Family
Identifier).
-* IPv4 EOR is an empty Update message
+* IPv4 EOR is an empty Update message.
* Ipv6 EOR is an Update message with empty MP_UNREACH attribute where
AFI and SAFI (Subsequent Address Family Identifier) are set to Ipv6.
-OpenDaylight also supports EOR for IPv4 in this format
+OpenDaylight also supports EOR for IPv4 in this format.
* Linkstate EOR is an Update message with empty MP_UNREACH attribute
-where AFI and SAFI are set to Linkstate
+where AFI and SAFI are set to Linkstate.
For BGP connections, where both peers support graceful restart, the EORs
are sent by the BGP speaker and are redirected to RIB, where the specific
AFI/SAFI table is set to _true_. Without graceful restart, the
messages are generated by OpenDaylight itself and sent after second keepalive for
each AFI/SAFI. This is done in
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/lithium[BGPSynchronization]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPSynchronization.java;hb=refs/heads/stable/beryllium[BGPSynchronization].
*Peers*
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/lithium[BGPPeer]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/BGPPeer.java;hb=refs/heads/stable/beryllium[BGPPeer]
has various meanings. If you configure BGP listener, _BGPPeer_
represents the BGP listener itself. If you are configuring BGP speaker,
you need to provide a list of peers, that are allowed to connect to this
speaker. Unknown peer represents, in this case, a peer that is allowed
to be refused. _BGPPeer_ represents in this case peer, that is supposed
-to connect to your speaker. _BGPPeer_ is stored in _https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/lithium[BGPPeerRegistry]_.
+to connect to your speaker. _BGPPeer_ is stored in https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/StrictBGPPeerRegistry.java;hb=refs/heads/stable/beryllium[BGPPeerRegistry].
This registry controls the number of sessions. Our strict implementation
limits sessions to one per peer.
-_https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/lithium[ApplicationPeer]_
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/ApplicationPeer.java;hb=refs/heads/stable/beryllium[ApplicationPeer]
is a special case of peer, that has it's own RIB. This RIB is populated
from RESTCONF. The RIB is synchronized with default BGP RIB. Incoming
routes to the default RIB are treated in the same way as they were from a
==== RIB handling
RIB (Route Information Base) is defined as a concept in
-http://tools.ietf.org/html/rfc4271#section-3.2[RFC4271]. RFC does not
+http://tools.ietf.org/html/rfc4271#section-3.2[RFC 4271]. RFC does not
define how it should be implemented. In our implementation,
-the routes are stored in MD-SALs data-store. There are four supported
+the routes are stored in the MD-SAL datastore. There are four supported
routes - _Ipv4Routes_, _Ipv6Routes_, _LinkstateRoutes_ and
_FlowspecRoutes_.
Each route type needs to provide a
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/lithium[RIBSupport.java]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-spi/src/main/java/org/opendaylight/protocol/bgp/rib/spi/RIBSupport.java;hb=refs/heads/stable/beryllium[RIBSupport.java]
implementation. _RIBSupport_ tells RIB how to parse binding-aware data
(BGP Update message) to binding-independent (datastore format).
image::bgpcep/RIB.png[height="450px", width="550px",title="RIB"]
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/lithium[AdjRibInWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibInWriter.java;hb=refs/heads/stable/beryllium[AdjRibInWriter]*
- represents the first step in putting data to datastore. This writer is
notified whenever a peer receives an Update message. The message is
transformed into binding-independent format and pushed into datastore to
_adj-rib-in_. This RIB is associated with a peer.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/lithium[EffectiveRibInWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/EffectiveRibInWriter.java;hb=refs/heads/stable/beryllium[EffectiveRibInWriter]*
- this writer is notified whenever _adj-rib-in_ is updated. It applies
all configured import policies to the routes and stores them in
_effective-rib-in_. This RIB is also associated with a peer.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/lithium[LocRibWriter]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/LocRibWriter.java;hb=refs/heads/stable/beryllium[LocRibWriter]*
- this writer is notified whenever *any* _effective-rib-in_ is updated
(in any peer). Performs best path selection filtering and stores the
routes in _loc-rib_. It also determines which routes need to be
advertised and fills in _adj-rib-out_ that is per peer as well.
-*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/lithium[AdjRibOutListener]*
+*https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/rib-impl/src/main/java/org/opendaylight/protocol/bgp/rib/impl/AdjRibOutListener.java;h=a14fd54a29ea613b381a36248f67491d968963b8;hb=refs/heads/stable/beryllium[AdjRibOutListener]*
- listens for changes in _adj-rib-out_, transforms the routes into
BGPUpdate messages and sends them to its associated peer.
=== BGP inet
This module contains only one YANG model
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/lithium[bgp-inet.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/inet/src/main/yang/bgp-inet.yang;hb=refs/heads/stable/beryllium[bgp-inet.yang]
that summarizes the ipv4 and ipv6 extensions to RIB routes and BGP
messages.
=== BGP flowspec
BGP flowspec is a module that implements
-http://tools.ietf.org/html/rfc5575[RFC5575]. The RFC defines an
-extension to BGP in form of a new subsequent address family, NLRI and
+http://tools.ietf.org/html/rfc5575[RFC 5575] for IPv4 AFI and https://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-06[draft-ietf-idr-flow-spec-v6-06] for IPv6 AFI.
+The RFC defines an extension to BGP in form of a new subsequent address family, NLRI and
extended communities. All of those are defined in the
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/lithium[bgp-flowspec.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/flowspec/src/main/yang/bgp-flowspec.yang;hb=refs/heads/stable/beryllium[bgp-flowspec.yang]
model. In addition to generated sources, the module contains parsers for
newly defined elements and RIBSupport for flowspec-routes. The route key of
flowspec routes is a string representing human-readable flowspec
version 04. The draft defines an extension to BGP in form of a new
address family, subsequent address family, NLRI and path attribute. All
of those are defined in the
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/lithium[bgp-linkstate.yang]
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/yang/bgp-linkstate.yang;hb=refs/heads/stable/beryllium[bgp-linkstate.yang]
model. In addition to generated sources, the module contains
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/lithium[LinkstateAttributeParser],
-https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/lithium[LinkstateNlriParser],
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/attribute/LinkstateAttributeParser.java;hb=refs/heads/stable/beryllium[LinkstateAttributeParser],
+https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=bgp/linkstate/src/main/java/org/opendaylight/protocol/bgp/linkstate/nlri/LinkstateNlriParser.java;hb=refs/heads/stable/beryllium[LinkstateNlriParser],
activators for both, parser and RIB, and RIBSupport handler for
linkstate address family. As each route needs a key, in case of
linkstate, the route key is defined as a binary string, containing all
-the nlri serialized to byte format.
+the NLRI serialized to byte format.
+The BGP linkstate extension also supports distribution of MPLS TE state as defined in https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-03[draft-ietf-idr-te-lsp-distribution-03],
+extension for Segment Routing https://tools.ietf.org/html/draft-gredler-idr-bgp-ls-segment-routing-ext-00[draft-gredler-idr-bgp-ls-segment-routing-ext-00] and
+Segment Routing Egress Peer Engineering https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-02[draft-ietf-idr-bgpls-segment-routing-epe-02].
+
+=== BGP labeled-unicast
+
+BGP labeled unicast is a module that implements https://tools.ietf.org/html/rfc3107[RFC 3107]. The RFC defines an extension to the BGP MP to carry Label Mapping Information
+as a part of the NLRI. The AFI indicates, as usual, the address family of the associated route. The fact that the NLRI contains a label
+is indicated by using SAFI value 4. All of those are defined in https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob_plain;f=bgp/labeled-unicast/src/main/yang/bgp-labeled-unicast.yang;hb=refs/heads/stable/beryllium[bgp-labeled-unicast.yang] model. In addition to the generated sources,
+the module contains new NLRI codec and RIBSupport. The route key is defined as a binary, where whole NLRI information is encoded.
=== BGP topology provider
== BGP User Guide ==
-=== Overview ===
-The OpenDaylight Karaf distribution comes pre-configured with baseline BGP
-configuration. You can find it in the etc/opendaylight/karaf directory and it
+=== 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* (which contains a sample configuration which needs to be
+`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.
-=== Configuring BGP ===
-
==== RIB ====
+
+The configuration of the Routing Information Base (RIB) is specified using a block in the `41-bgp-example.xml` file.
+
[source,xml]
----
<module>
</module>
----
-- *rib-id* - BGP RIB Identifier, in this configuration file you can specify more BGP RIBs by
-copy-pasting the above module. These RIBs must have a unique rib-id and name.
-- *local-as* - Our local AS number (where OpenDaylight is deployed), we use this in best path selection
-- *bgp-id* - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed),
+- *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, non-mandatory, if not specified, BGP Identifier will be used
+- *cluster-id* - cluster identifier, optional, if not specified, BGP Identifier will be used
-MIGHT NOT BE NEEDED: depending on your BGP router, you might need to switch from
+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.
+This snippet is located in `31-bgp.xml` file.
[source,xml]
----
----
- *iana-linkstate-attribute-type* - IANA has issued an early allocation for the
-BGP Linkstate path attribute (=29). To preserve (TYPE = 99) set value bellow
+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 ====
</module>
----
-- *name* - BGP Peer name, in this configuration file you can specify more BGP Peers by copy-pasting the above module. These peers must have a *unique* name.
-- *host* - IP address or hostname of BGP speaker (IP where OpenDaylight should connect to gather topology)
-- *holdtimer* - unit: seconds
-- *peer-role* - If peer role is not present, default value "ibgp" will be used (allowed values are also "ebgp" and "rr-client"). This field is case-sensitive.
+- *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 ====
+==== Configure Connection Attributes (Optional) ====
[source,xml]
----
</module>
----
-- *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
-- *connect-time* - How long we should wait (miliseconds) for the TCP connect
-attempt, overrides default connection timeout dictated by TCP retransmits
+- *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 ====
-Previous entries addressed the configuration of a BGP connection initiated by
-OpenDaylight. OpenDaylight also supports BGP Speaker functionality and accepts
-incoming BGP connections.
+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:
+The configuration of BGP speaker is located in: `41-bgp-example.xml`:
[source,xml]
----
</module>
----
-*Changing speaker configuration*
- 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[BGP RFC]. --
+ _1790_. The default binding port is _179_ as specified in link:http://tools.ietf.org/html/rfc4271[RFC 4271].
==== Incomming BGP Connections ====
-*BGP speaker drops all BGP connections from unknown BGP peers.* The decision is
+*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).
+registry is configured in `31-bgp.xml`).
-To add 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
+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]
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. Note, that the name of the module needs to be
-unique, so if you are configuring more peers, when changing the *host*, change
-also the *name*.
-There is a way to configure the peer only for incoming connections (The
-connection will not be initiated by the OpenDaylight, OpenDaylight will only wait for incoming
-connection from the peer. The peer is identified by its IP address). To
-configure peer only for incoming connection add attribute initiate-connection
-to peer's configuration:
+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]
----
</module>
----
-- *initiate-connection* - if set to false OpenDaylight will not initiate connection to this peer. Default value is true for all peers.
+- *initiate-connection* - if set to false OpenDaylight will not initiate connection to this peer. Default value is true.
==== BGP Application Peer ====
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 value in bold bgp-peer-id which is your local BGP-ID that will be
-used in BGP Best Path Selection algorithm.
+Change the bgp-peer-id, which is your local BGP ID that will be
+used in BGP best path selection algorithm.
[source,xml]
----
</module>
----
-- *bgp-peer-id* - Our local BGP identifier (the IP of the VM where OpenDaylight is deployed), we use this in best path selection
+- *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. Before you
-start, make sure, you've completed steps 1-5 in Installation Guide. Instead of
+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
+ 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.
==== RIB ====
-First, configure RIB. This module is already present in the configuration,
+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:* _
+*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:*
</local-table>
<local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type>bgp-table-type</type>
- <name>flowspec</name>
+ <name>ipv4-flowspec</name>
+ </local-table>
+ <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type>bgp-table-type</type>
+ <name>ipv6-flowspec</name>
+ </local-table>
+ <local-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type>bgp-table-type</type>
+ <name>labeled-unicast</name>
</local-table>
<bgp-rib-id xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">192.0.2.2</bgp-rib-id>
+ <openconfig-provider xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp-openconfig-spi">x:bgp-openconfig-provider</type>
+ <name>openconfig-bgp</name>
+ </openconfig-provider>
</module>
----
-IMPORTANT: MIGHT NOT BE NEEDED depending on your BGP router, you might need a
-switch from linkstate attribute type 99 to 29. Check with your router vendor.
-Switch the field to true if your router supports type 29.
+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_
==== BGP Peer ====
-We also need to add new module to configuration (bgp-peer). In this case, the
+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).
-.*POST:*
+*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]
----
</advertized-table>
<advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
<type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
- <name>flowspec</name>
+ <name>ipv4-flowspec</name>
+ </advertized-table>
+ <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
+ <name>ipv6-flowspec</name>
+ </advertized-table>
+ <advertized-table xmlns="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">
+ <type xmlns:x="urn:opendaylight:params:xml:ns:yang:controller:bgp:rib:impl">x:bgp-table-type</type>
+ <name>labeled-unicast</name>
</advertized-table>
</module>
----
Change the value *bgp-peer-id* which is your local BGP ID that will be used in
BGP Best Path Selection algorithm.
-.*POST:*
+*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]
----
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">
This section summarizes how data from BGP can be viewed through RESTCONF. Currently it is the only way to view the data.
-IMPORTANT: From Helium release the port changed from 8080 to 8181.
-
===== Network Topology View =====
-Basic URL for network topology is *http://localhost:8181/restconf/operational/network-topology:network-topology/* .
+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 this one:
+If BGP is configured properly, it should display output similar to:
[source,xml]
----
</network-topology>
----
-BGP data as were sent from BGP speaker are listed in three topologies (if all three are configured):
+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
+* *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
+** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-linkstate-topology
-*example-ipv4-topology* - display Ipv4 adresses of nodes in the 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
+** http://localhost:8181/restconf/operational/network-topology:network-topology/topology/example-ipv4-topology
-*example-ipv6-topology* - display Ipv6 adresses of nodes in the 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
+** 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/
+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:
- 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 output looks like, when address families for IPv4 and Linkstate were configured:
+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]
----
-<loc-rib>
- <tables>
- </attributes>
- <safi>x:linkstate-subsequent-address-family</safi>
- <afi>x:linkstate-address-family</afi>
- </linkstate-routes>
- </tables>
- <tables>
- </attributes>
- <safi>x:unicast-subsequent-address-family</safi>
- <afi>x:ipv4-address-family</afi>
- </ipv4-routes>
- </tables>
+<loc-rib xmlns="urn:opendaylight:params:xml:ns:yang:bgp-rib">
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ </ipv6-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:unicast-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ </ipv4-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">x:flowspec-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <flowspec-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ </flowspec-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv6-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">x:flowspec-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <flowspec-ipv6-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ </flowspec-ipv6-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">x:labeled-unicast-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <labeled-unicast-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ </labeled-unicast-routes>
+ </tables>
+ <tables>
+ <afi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-address-family</afi>
+ <safi xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">x:linkstate-subsequent-address-family</safi>
+ <attributes>
+ <uptodate>false</uptodate>
+ </attributes>
+ <linkstate-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-linkstate">
+ </linkstate-routes>
+ </tables>
</loc-rib>
----
You can see details for each AFI by expanding the RESTCONF link:
-*IPv4* : 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
+* *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
+* *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 your peer is configured, you can populate the RIB by making following POST call to RESTCONF:
+If an application peer is configured, you can populate its RIB by making POST calls to RESTCONF like the following.
-*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/
+===== 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.
-*POST:*
+*Method:* POST
*Content-Type:* application/xml
[source,xml]
----
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<ipv4-routes xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
- <ipv4-route>
- <prefix>200.20.160.1/32</prefix>
+ <?xml version="1.0" encoding="UTF-8" standalone="no"?>
+ <ipv4-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <prefix>1.1.1.1/32</prefix>
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.160.41</global>
+ </ipv4-next-hop><as-path/>
+ <multi-exit-disc>
+ <med>0</med>
+ </multi-exit-disc>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <originator-id>
+ <originator>41.41.41.41</originator>
+ </originator-id>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <cluster-id>
+ <cluster>40.40.40.40</cluster>
+ </cluster-id>
+ </attributes>
+ </ipv4-route>
+----
+
+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/<route-id>
+
+*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]
+----
+ <ipv6-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-inet">
+ <prefix>2001:db8:30::3/128</prefix>
+ <attributes>
+ <ipv6-next-hop>
+ <global>2001:db8:1::6</global>
+ </ipv6-next-hop>
+ <as-path/>
+ <origin>
+ <value>egp</value>
+ </origin>
+ </attributes>
+ </ipv6-route>
+----
+
+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/<route-id>
+
+*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]
+----
+ <labeled-unicast-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-labeled-unicast">
+ <route-key>label1</route-key>
+ <prefix>1.1.1.1/32</prefix>
+ <label-stack>
+ <label-value>123</label-value>
+ </label-stack>
+ <label-stack>
+ <label-value>456</label-value>
+ </label-stack>
+ <label-stack>
+ <label-value>342</label-value>
+ </label-stack>
+ <attributes>
+ <ipv4-next-hop>
+ <global>199.20.160.41</global>
+ </ipv4-next-hop>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ </attributes>
+ </labeled-unicast-route>
+----
+
+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/<route-id>
+
+*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]
+----
+<flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow1</route-key>
+ <flowspec>
+ <destination-prefix>192.168.0.1/32</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>10.0.0.1/32</source-prefix>
+ </flowspec>
+ <flowspec>
+ <protocol-ips>
+ <op>equals end-of-list</op>
+ <value>6</value>
+ </protocol-ips>
+ </flowspec>
+ <flowspec>
+ <ports>
+ <op>equals end-of-list</op>
+ <value>80</value>
+ </ports>
+ </flowspec>
+ <flowspec>
+ <destination-ports>
+ <op>greater-than</op>
+ <value>8080</value>
+ </destination-ports>
+ <destination-ports>
+ <op>and-bit less-than end-of-list</op>
+ <value>8088</value>
+ </destination-ports>
+ </flowspec>
+ <flowspec>
+ <source-ports>
+ <op>greater-than end-of-list</op>
+ <value>1024</value>
+ </source-ports>
+ </flowspec>
+ <flowspec>
+ <types>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </types>
+ </flowspec>
+ <flowspec>
+ <codes>
+ <op>equals end-of-list</op>
+ <value>0</value>
+ </codes>
+ </flowspec>
+ <flowspec>
+ <tcp-flags>
+ <op>match end-of-list</op>
+ <value>32</value>
+ </tcp-flags>
+ </flowspec>
+ <flowspec>
+ <packet-lengths>
+ <op>greater-than</op>
+ <value>400</value>
+ </packet-lengths>
+ <packet-lengths>
+ <op>and-bit less-than end-of-list</op>
+ <value>500</value>
+ </packet-lengths>
+ </flowspec>
+ <flowspec>
+ <dscps>
+ <op>equals end-of-list</op>
+ <value>20</value>
+ </dscps>
+ </flowspec>
+ <flowspec>
+ <fragments>
+ <op>match end-of-list</op>
+ <value>first</value>
+ </fragments>
+ </flowspec>
+ <attributes>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
+ <extended-communities>
+ ....
+ </extended-communities>
+ </attributes>
+</flowspec-route>
+----
+
+*Flowspec Extended Communities (Actions):*
+
+[source,xml]
+----
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-rate-extended-community>
+ <informative-as>123</informative-as>
+ <local-administrator>AAAAAA==</local-administrator>
+ </traffic-rate-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-action-extended-community>
+ <sample>true</sample>
+ <terminal-action>false</terminal-action>
+ </traffic-action-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-extended-community>
+ <global-administrator>123</global-administrator>
+ <local-administrator>AAAAew==</local-administrator>
+ </redirect-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ipv4>
+ <global-administrator>192.168.0.1</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv4>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-as4>
+ <global-administrator>64495</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-as4>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <redirect-ip-nh-extended-community>
+ <copy>false</false>
+ </redirect-ip-nh-extended-community>
+ </extended-communities>
+
+ <extended-communities>
+ <transitive>true</transitive>
+ <traffic-marking-extended-community>
+ <global-administrator>20</global-administrator>
+ </traffic-marking-extended-community>
+ </extended-communities>
+----
+
+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/<route-id>
+
+*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]
+----
+<flowspec-route xmlns="urn:opendaylight:params:xml:ns:yang:bgp-flowspec">
+ <route-key>flow-v6</route-key>
+ <flowspec>
+ <destination-prefix>2001:db8:30::3/128</destination-prefix>
+ </flowspec>
+ <flowspec>
+ <source-prefix>2001:db8:31::3/128</source-prefix>
+ </flowspec>
+ <flowspec>
+ <flow-label>
+ <op>equals end-of-list</op>
+ <value>1</value>
+ </flow-label>
+ </flowspec>
<attributes>
- <ipv4-next-hop>
- <global>199.20.160.41</global>
- </ipv4-next-hop><as-path/>
- <multi-exit-disc>
- <med>0</med>
- </multi-exit-disc>
- <local-pref>
- <pref>100</pref>
- </local-pref>
- <originator-id>
- <originator>41.41.41.41</originator>
- </originator-id>
- <origin>
- <value>igp</value>
- </origin>
- <cluster-id>
- <cluster>40.40.40.40</cluster>
- </cluster-id>
+ <extended-communities>
+ <redirect-ipv6>
+ <global-administrator>2001:db8:1::6</global-administrator>
+ <local-administrator>12345</local-administrator>
+ </redirect-ipv6>
+ </extended-communities>
+ <origin>
+ <value>igp</value>
+ </origin>
+ <as-path/>
+ <local-pref>
+ <pref>100</pref>
+ </local-pref>
</attributes>
- </ipv4-route>
-</ipv4-routes>
+</flowspec-route>
----
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/<route-id>
+
+*Method:* DELETE
\ No newline at end of file
Code Review / docs.git / commitdiff