How Can We Help?
EBGP-based Data Center with OcNOS
Data Center Interconnect Overview
Large-Scale Data Center Requirements
Large-Scale Data Center Topologies
Large-Scale Data Center Routing
EBGP-Routed Clos Topology-Based Data Center
EBGP Data Center Design using OcNOS
Configuration 8
Appendix A: Configuring the Data Center through NetConf
Appendix B: NetConf User Guide
Glossary
BGP | Border Gateway Routing Protocol |
EBGP | External BGP |
STP | Spanning Tree Protocol |
TRILL | Transparent Interconnection of Lots of Links |
SPB | Shortest Path Bridging |
ECMP | Equal Cost Multipath |
Chapter 1
Data Center Overview
Network Automation provides IT administrators and network operators significant benefits. This solution guide
describes an approach to build data centers using Layer3 BGP routing protocol.
It also summarizes on some design philosophies for data center and why E-BGP is better suited.
- Large-scaledata center requirements
- Large-scaledata center topologies
- Large-scaledata center routing
- EBGP-routedlarge-scale Clos topology-based data center
Large-Scale Data Center Requirements
The design of large-scale data centers is driven by operational simplicity and network stability. Operational simplicity and network stability ensures easier manageability and therefore reduced operational expenses. From the network design aspect, the requirements are:
- Abilityto accommodate the variable-application bandwidth and strict latency
- Abilityto handle the increased east-west (server-to-server) traffic within the data center due to massive
data replication between clusters and virtual machine migrations.
- Traffic-Engineeringwith application load The network infrastructure should itself perform controlled per-hop traffic engineering.
- MinimizeCAPEX and incorporate vendor diversity by using a simple, interoperable routing protocol with a minimal set of
- Adesign to minimize OPEX by keeping the failure domain at the lowest level in the network
Large-Scale Data Center Topologies
A traditional tree-based (upside down) topology with a three-layer hierarchy of core, aggregation and access
layer can be used in a data center design. This approach is suited if the majority of the traffic is entering
and leaving (north-south) the data center. An increase in bandwidth requirements then can be addressed by upgrading the device line cards or port density. However with the current trend of increasing server-to-server (east-west) traffic, scaling these networks horizontally is expensive or impossible at times.
A Clos network (leaf and spine) is a horizontally scalable topology where every leaf node is connected to every other spine. The topology can be extended to different stages for scaling. Clos networks are fully non- blocking and load balancing is inherent in the topology itself as all available paths are ECMP. Clos networks are ideal for the current requirements of a large-scale data center.
Large-Scale Data Center Routing
Layer 2-only routing was used in a traditional tree-based data center topology. Traditional layer-2 protocols such as STP do not give bi-sectional bandwidth, whereas recent developments such as TRILL, SPB have selected vendor support.
However, a hybrid of layer 2 /layer 3 can be used to limit the size of failure domain and scale up the data center. Layer 3 routing can be used in tier 1 (core) and layer 2 in tier 3 (access). Tier 2 can be based on either layer 2 or layer 3. A hybrid model has the advantage of seamless Virtual Machine mobility and requires less IP subnets for the data center. Although this design can scale-up, it is difficult and complex to manage the different protocols.
A layer 3 only design simplifies the network and improves network stability and scalability, as well as
localizing the failure domain (confined to the L2 broadcast domain). Seamless virtual mobility can be achieved in a L3 only based data center by using L2 overlay networks. From experiment and analysis, External BGP (EBGP) is considered ideal compared to IGPs due to the following [See Reference]:
- Lesscomplex protocol, simple state machine
- Informationflooding overhead is less, no frequent updates unlike IGPs
- Networkfailure recovery is very Although BGP convergence is slower than IGP, in a Clos topology with ECMP links, the failure is masked as soon as an alternate path is found.
- Failuredomain is minimized in a Clos topology with Some of the failures are local/hidden/not propagated if the failed link was not selected/advertised as the best path among the ECMP paths by the BGP speaker. The failures, where all devices have to withdraw some prefixes or update the ECMP groups in the FIB, are very limited and in those failures the failed link/node does not impact the re-convergence process.
- Administratorcan define the application traffic BGP provides services like prefix distribution, prefix filtering, traffic engineering, traffic tagging, and multi-vendor stability better than other IGPs.
- Easierto
EBGP-Routed CLOS Topology-Based Data Center
EBGP-routed CLOS topology is considered the best choice for laying the IP fabric in a data center because of the horizontal scalability feature of Clos topology and the ease of use and services provided by EBGP especially prefix-filtering, prefix distribution, and traffic engineering which are required extensively in a data center.
Configuration Guidelines
Configuration guidelines for laying IP fabric using EBGP efficiently are as follows:
- Runall EBGP sessions over single-hop point-to-point
- Useprivate Autonomous System Numbers (ASNs) (64512-65534) to avoid ASN
- Giveall tier 1 (core) devices a single
- Giveall tier 2 devices in the same cluster the same unique A cluster or pod is a group of tier 2 (spine switches) + tier 3 switches (ToR/leaf) + servers.
- Giveevery tier 3 (ToR) device in a cluster a unique
- Reusetier-3 ASNs across Configure tier-3 devices with the BGP “allowas-in” feature to allow route learning of prefixes from the same ASNs in other clusters.
- Announceserver subnets on tier-3 devices via BGP without using route summarization on tier-2 and tier-1
- Useedge clusters (pods) for external connectivity. Each edge cluster consists of border routers (tier-2) and WAN routers (tier-3). Give each WAN router a unique public ASN to connect the data center to the external world.
- Forborder routers, remove private ASNs before sending the information to WAN routers by configuring border routers with the “remove-private-AS” BGP
- Torelax the BGP ECMP criteria for AS paths, configure BGP “as-path multipath-relax” on all routers/ This way, an equal cost path with a different AS PATH, but the same AS PATH length is also considered an equal cost path (ECMP).
- Forfaster failure detection, configure the BGP session with
- Toavoid recurring BPG update/selection for a single failure through all peers or BGP update message dispersion on a particular speaker, use BGP update The BGP update group feature processes an update once and sends it to a group of neighbors that share a common outbound policy. The BGP RIB is scanned every time for each peer to apply the outbound filter.
- Toavoid micro routing loops, configure tier-2 and tier-1 with static discard or null routes rather than a default Routing loops can happen when a tier-2 device has lost all its learned prefixes, but has a default
route to a tier-1 device and that tier-1 device still has a route back to the tier-2 device.
EBGP Data Center Design using OcNOS
Figure-1 shows a minimal representation that encompasses all the elements in a layer 3 data center. The number of ECMPs in the data center is equal to the number of cores (tier-1 switches).
Figure 1 . IP fabric using EBGP
Core Tier 1
Figure 2 shows the Autonomous System Number (ASN) allocation scheme used in the data center. The WAN routers are assigned a public ASN, which connects the data center to external world. The tier-3 ASNs per ToR are reused across the clusters.
Figure 2: ASN allocation in an EBGP-based data center
ASN 65534
Chapter 2
Configuration
To R (Leaf node)
Command | Purpose | |
Step 1 | (config)#interface xe1 | Enter interface mode. |
Step 2 | (config-if)#ip address 32.1.0.3/24 | Configure ip address on the Interface |
Step 3 | (config-if)#exit | Exit interface mode. |
Step 4 | (config)#interface xe2 | Enter interface mode. |
Step 5 | (config-if)#exit | Exit interface mode. |
Step 6 | (config)#router bgp 65500 | Configure the EBGP routing process with private ASN |
Step 7 | (config-router)#max-paths ebgp 8 | Exit interface mode. |
Step 8 | (config-router)#neighbor 32.1.0.2 remote-as 64601 | Configure maximum EBGP ECMP that can be installed in BGP. |
Step 9 | (config-router)#neighbor 32.1.0.2 fall-over bfd | Configure the EBGP neighbor over the connected interface using the neighbor IP and remote private ASN |
Step 10 | (config-router)#neighbor 32.1.0.2 allowas-in | Configure BFD for the BGP session for faster failure detection. |
Step 11 | (config-router)#neighbor 32.2.0.2 remote-as 64601 | Configure “allowas-in” for the neighbor to accept routes with same ASN learned over this neighbor |
Step 12 | (config-router)#neighbor 32.2.0.2 fall-over bfd | Configure the EBGP neighbor over the connected interface using the neighbor IP and remote private ASN |
Step 13 | (config-router)#neighbor 32.2.0.2 allowas-in | Configure BFD for the BGP session for faster failure detection. |
Step 14 | (config-router)#exit | Configure “allowas-in” for the neighbor to accept routes with same ASN learned over this neighbor |
Step 15 | (config-router)#exit | Exit Router mode. |
Tier-2 (Spine node)
Command | Purpose | |
Configure the interfaces | ||
Step 1 | (config)#interface xe1 | Enter interface mode. |
Step 2 | (config-if)#ip address 32.1.0.2/24 | Configure ip address on the interface |
Step 3 | (config-if)#exit | Exit interface mode. |
Step 4 | (config)#interface xe46 | Enter interface mode. |
Step 5 | (config-if)#ip address 32.3.0.2/24 | Configure an IP address on the interface |
Step 6 | (config)#interface xe47 | Enter interface mode. |
Step 7 | (config-if)#ip address 32.4.0.2/24 | Configure an IP address on the interface |
Step 8 | (config)#interface xe48 | Enter interface mode. |
Step 9 | (config-if)#ip address 21.1.0.2/24 | Configure an IP address on the interface |
Step 10 | (config)#interface xe46 | Enter interface mode. |
Step 11 | (config-if)#ip address 21.2.0.2/24 | Configure an IP address on the interface |
Step 12 | (config)#router bgp 64601 | Configure the eBGP routing process with private ASN |
Tier-2 (Spine node) cont.
Command | Purpose | |
Configure BGP on the router | ||
Step 13 | (config-router)#bgp bestpath as-path multipath-relax | Configure “as-path multipath-relax” to relax the AS-PATH exact match (if AS-PATH length are same) criteria for BGP ECMP |
Step 14 | (config-router)#max-paths ebgp 8 | Configure maximum EBGP ECMP that can be installed in BGP. |
Step 15 | (config-router)#neighbor 32.1.0.3 remote-as 65000 | Configure the EBGP neighbor over the connected interface using the neighbor IP and remote ASN |
Step 16 | (config-router)#neighbor 32.1.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure detection. |
Step 17 | (config-router)#neighbor 32.3.0.3 remote-as 65001 | Configure the EBGP neighbor over the connected interface using the neighbor IP and remote ASN |
Step 18 | (config-router)#neighbor 32.3.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure detection. |
Step 19 | (config-router)#neighbor 32.4.0.3 remote-as 65002 | Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 20 | (config-router)#neighbor 32.1.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 21 | (config-router)#neighbor 21.1.0.1 remote-as 65534 | Configure the EBGP neighbor over the connected interface using the neighbor IP and remote ASN |
Step 22 | (config-router)#neighbor 21.1.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure detection. |
Step 23 | (config-router)#neighbor 21.2.0.1
remote-as 65534 |
Configure the EBGP neighbor over the connected interface using the neighbor IP and remote ASN |
Step 24 | (config-router)#neighbor 21.2.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure detection. |
Step 25 | (config-router)#exit | Exit Router mode. |
Tier-3 (Core node)
Command | Purpose | |
Configure the interfaces | ||
Step 1 | (config)#interface xe1 | Enter interface mode. |
Step 2 | (config-if)#ip address 21.1.0.1/24 | Configure ip address on the interface |
Step 3 | (config-if)#exit | Exit interface mode. |
Step 4 | (config)#interface xe46 | Enter interface mode. |
Step 5 | (config-if)#ip address 21.5.0.1/24 | Configure an IP address on the interface |
Step 6 | (config)#interface xe49 | Enter interface mode. |
Step 7 | (config-if)#ip address 41.1.0.1/24 | Configure an IP address on the interface |
Step 8 | (config)#interface xe50 | Enter interface mode. |
Step 9 | (config-if)#ip address 41.5.0.1/24 | Configure an IP address on the interface |
Configure BGP on the router | ||
Step 10 | (config)#router bgp 65534 | Configure the eBGP routing process with private ASN |
Step 11 | (config-router)#bgp bestpath as-path multipath-relax | Configure “as-path multipath-relax” to relax the AS-PATH exact match (if AS-PATH length are same) criteria for BGP ECMP |
Step 12 | (config-router)#max-paths ebgp 8 | Configure maximum EBGP ECMP that can be installed
in BGP. |
Step 13 | (config-router)#neighbor 21.1.0.2
remote-as 64601 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 14 | (config-router)#neighbor 21.1.0.2 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 15 | (config-router)#neighbor 21.5.0.3
remote-as 64602 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 16 | (config-router)#neighbor 21.5.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 17 | (config-router)#neighbor 41.1.0.3
remote-as 64603 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 18 | (config-router)#neighbor 41.1.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 19 | (config-router)#neighbor 41.5.0.3
remote-as 64603 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 20 | (config-router)#neighbor 41.5.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 21 | (config-router)#exit | Exit BGP mode |
Tier 2 (Border router)
Command | Purpose | |
Configure the interfaces | ||
Step 1 | (config)#interface xe1 | Enter interface mode. |
Step 2 | (config-if)#ip address 41.1.0.2/24 | Configure an IP address on the interface |
Step 3 | (config-if)#exit | Exit interface mode. |
Step 4 | (config)#interface xe46 | Enter interface mode. |
Step 5 | (config-if)#ip address 41.2.0.2/24 | Configure an IP address on the interface |
Step 6 | (config)#interface xe47 | Enter interface mode. |
Step 7 | (config-if)#ip address 41.3.0.2/24 | Configure an IP address on the interface |
Step 8 | (config)#interface xe48 | Enter interface mode. |
Step 9 | (config-if)#ip address 41.4.0.2/24 | Configure an IP address on the interface |
Step 10 | (config)#interface xe49 | Enter interface mode. |
Step 11 | (config-if)#ip address 51.1.0.2/24 | Configure an IP address on the interface |
Step 12 | (config)#interface xe50 | Enter interface mode. |
Step 13 | (config-if)#ip address 51.3.0.2/24 | Configure an IP address on the interface |
Step 14 | (config)#router bgp 64603 | Configure the eBGP routing process with private ASN |
Step 15 | (config-router)#bgp bestpath as-path multipath-relax | Configure “as-path multipath-relax” to relax the AS-PATH exact match (if AS-PATH length are same) criteria for BGP ECMP |
Step 16 | (config-router)#max-paths ebgp 8 | Configure maximum EBGP ECMP that can be installed in BGP. |
Step 17 | (config-router)#neighbor 41.1.0.1
remote-as 65534 |
Configure the EBGP neighbor over the connected interface
using the neighbor IP and remote ASN |
Step 18 | (config-router)#neighbor 41.1.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 19 | (config-router)#neighbor 41.2.0.1
remote-as 65534 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 20 | (config-router)#neighbor 41.2.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 21 | (config-router)#neighbor 41.3.0.1
remote-as 65534 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 22 | (config-router)#neighbor 41.3.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 23 | (config-router)#neighbor 41.4.0.1
remote-as 65534 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 24 | (config-router)#neighbor 41.4.0.1 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 25 | (config-router)#neighbor 51.1.0.3
remote-as 100 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Configure BGP on the router | ||
Step 26 | (config-router)#neighbor 51.1.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 27 | (config-router)#neighbor 51.1.0.3 remove-private-AS | Configure “remove –private-AS” to remove the private ASNs
for the routes advertised to this neighbor. |
Step 28 | (config-router)#neighbor 51.3.0.3
remote-as 101 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Tier 2 (Border router) Cont.
Command | Purpose | |
Configure BGP on the router | ||
Step 29 | (config-router)#neighbor 51.3.0.3 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 30 | (config-router)#neighbor 51.3.0.3 remove-private-AS | Configure “remove –private-AS” to remove the private ASNs
for the routes advertised to this neighbor. |
Step 31 | (config-router)#exit | Exit BGP mode |
Tier-3 (WAN router)
This is a partial list and does not contain the Internet configuration.
Command | Purpose | |
Configure the interfaces | ||
Step 1 | (config)#interface xe1 | Enter interface mode. |
Step 2 | (config-if)#ip address 51.1.0.3/24 | Configure an IP address on the interface |
Step 3 | (config-if)#exit | Exit interface mode. |
Step 4 | (config)#interface xe46 | Enter interface mode. |
Step 5 | (config-if)#ip address 51.2.0.3/24 | Configure an IP address on the interface |
Configure BGP on the router | ||
Step 6 | (config)#router bgp 100 | Configure the eBGP routing process with public ASN |
Step 7 | (config-router)#max-paths ebgp 8 | Configure maximum EBGP ECMP that can be installed in
BGP. |
Step 8 | (config-router)#neighbor 51.1.0.2
remote-as 64603 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 9 | (config-router)#neighbor 51.1.0.2 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 10 | (config-router)#neighbor 51.3.0.2
remote-as 64603 |
Configure the EBGP neighbor over the connected
interface using the neighbor IP and remote ASN |
Step 11 | (config-router)#neighbor 51.3.0.2 fall-over bfd | Configure BFD for the BGP session for faster failure
detection. |
Step 12 | (config-router)#exit | Exit BGP mode |
You must repeat similar configurations for all ToR, spine, core, border, and WAN devices as well.
Use the show ip bgp command to validate the output at each node.
Consider the following case: for application load balancing and high availability/reliability, two similar application servers can be placed at two clusters. For users accessing the application server through the Internet, the access to the server is load balanced and failure of one of the application servers does not impact the accessibility. The following is the output at various nodes for a subnet, such as:
- 70.70.70.1(application server) at ToR1 in cluster 1 and cluster 2
- 80.80.80.1at ToR 1 cluster 1
- 90.90.1at ToR 1 cluster 2
OcNOS with EBGP routing is a highly scalable, simple and flexible way of laying IP fabric in a data center.
The data center can be easily scaled for:
- Highercomputing needs by adding more
- Higherperformance and redundancy by adding more cores
- Higheruplink speeds by adding more external/edge
Use of BGP for routing in large scale data centers: https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-routing-large-dc-09
Appendix A: Configuring the Data
Center through NetConf
This appendix shows how to configure a data center through NetConf. This section contains XML payloads which can be used by any NetConf client to send configurations to OcNOS devices.
The configurations below in XML are communicated via RPC messages from the NetConf client to the
NetConf server.
This document uses the yang-cli which is part of open source OpenYumaMaster which and is preinstalled on a ZebM-enabled OcNOS ONIE package as a NetConf client.
Pre-requisite
Refer to Yangcli Operations section of the NetConf User Guide and perform these operations first:
- EstablishConnection
- LoadModules
Once the above operations are complete, edit-config operation can be performed with XML payloads using
the command:
yangcli ocnos@Hostname> edit-config config=@/<path-to-xml-file>/<xml-file>.xml
Save the below xml payloads as an .xml file in any desired location. Make sure that each XML payload starts
with <vr xmlns=”<namespace>”> and ends with </vr>.
TOR (leaf node) TOR.xml
This table shows the XML to configure an IP address:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ ZebOS”> | namespace of the ZebOS module |
<vrId>0</vrId> | Vrid |
<interface>
<ifName>xe49</ifName> <ipAddr>50.52.1.1/24</ipAddr> </interface> <interface> <ifName>ge2</ifName> <ipAddr>50.54.1.1/24</ipAddr> </interface> |
Configure the interfaces which are connected to the
SPINE routers. This payload configures the IP address of the interfaces xe49 and ge2. |
</vr> | Close namespace for the ZebOS module |
This is an example of the XML payload to be sourced in the yang CLI to configure an interface IP addresses:
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”>
<vrId>0</vrId>
<interface>
<ifName>xe49</ifName>
<ipAddr>50.52.1.1/24</ipAddr>
</interface>
<interface>
<ifName>ge2</ifName>
<ipAddr>50.54.1.1/24</ipAddr>
</interface>
</vr>
This table shows the XML to configure BGP attributes:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ ZebOS”> | Namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<bgp>
<bgpAs>64602</bgpAs> |
Open BGP tag.
Configure the BGP AS number. |
<multipathRelax>1</multipathRelax>
<vrfName>default</vrfName> |
Configure “as-path multipath-relax” to
relax the AS-PATH criteria for BGP ECMP |
<multipath>
<bgpType>ebgp</bgpType> <multipathType> <multipathsNum>8</ multipathsNum> </multipathType> </multipath> |
Configure maximum EBGP ECMP that can be
installed in BGP. |
<bgpPeer>
<peerAddr>50.52.1.2</peerAddr> <allowAsNum>3</allowAsNum> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>64902</peerAs> </bgpPeer> |
Configure BGP peer with AS 64902 and peer
address 50.52.1.2 Enable BFD for link failure detection Configure “allowas” in for the neighbor to accept routes with same ASN learned over this neighbor |
<bgpPeer>
<peerAddr>50.54.1.2</peerAddr> <allowAsNum>3</allowAsNum> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>64902</peerAs> </bgpPeer> |
Configure BGP peer with AS 64902 and peer
address 50.54.1.2 Configure “allowas” in for the neighbor to accept routes with same ASN learned over this neighbor Enable BFD for link failure detection. |
<bgpRedistList>
<redistType>connected</redistType> </bgpRedistList> <bgpRedistList> <redistType>ospf</redistType> </bgpRedistList> |
Redistribute the connected and OSPF routes |
</bgp> | Close BGP tag. |
</vr> | Close namespace for the ZebOS module |
Tier-2 (spine node) SPINE.xml
This table shows the XML to configure IP addresses:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<interface>
<ifName>xe49/1</ifName> <ipAddr>50.52.1.2/24</ipAddr> </interface> <interface> <ifName>xe49/2</ifName> <ipAddr>52.31.1.1/24</ipAddr> </interface> |
Configure the interfaces which are connected
to the SPINE routers. This payload configures the IP address of the interfaces xe49/1 and xe49/2. |
</vr> | Close namespace for the ZebOS module |
This table shows the XML to configure BGP attributes:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<bgp>
<bgpAs>64902</bgpAs> |
Open BGP tag.
Configure the BGP AS number. |
<multipathRelax>1</multipathRelax>
<vrfName>default</vrfName> |
Configure “as-path multipath-relax” to relax the
AS-PATH criteria for BGP ECMP |
<multipath>
<bgpType>ebgp</bgpType> <multipathType> <multipathsNum>8</multipathsNum> </multipathType> </multipath> |
Configure maximum EBGP ECMP that can be
installed in BGP. |
<bgpRedistList>
<redistType>connected</redistType> </bgpRedistList> |
Redistribute the connected routes |
<bgpPeer>
<peerAddr>50.52.1.1</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>64601</peerAs> </bgpPeer> |
Configure BGP peer with AS 64602 and peer
address 50.52.1.1 Enable BFD for link failure detection. |
<bgpPeer>
<peerAddr>52.31.1.2</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>65501</peerAs> </bgpPeer> |
Configure BGP peer with AS 65501 and peer
address 52.31.1.2 Enable BFD for link failure detection. |
</bgp> | Close BGP tag. |
</vr> | Close namespace for the ZebOS module |
Tier-3 (core node) CORE.xml
This table shows the XML to configure IP addresses:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<interface>
<ifName>xe1</ifName> <linkStatus>1</linkStatus> <ipLabel>NULL</ipLabel> <ipAddr>52.31.1.2/24</ipAddr> </interface> <interface> <ifName>ge8</ifName> <linkStatus>0</linkStatus> <ipLabel>NULL</ipLabel> <ipAddr>31.22.1.1/24</ipAddr> </interface> |
Configure the interfaces that are connected to
the spine routers. This payload configures the IP address of the interfaces xe1 and ge8. |
</vr> | Close namespace for the ZebOS module |
This table shows the XML to configure BGP attributes:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<bgp>
<bgpAs>65501</bgpAs> |
Open BGP tag.
Configure the BGP AS number. |
<multipathRelax>1</multipathRelax>
<vrfName>default</vrfName> |
Configure “as-path multipath-relax” to relax
the AS-PATH criteria for BGP ECMP |
<multipath>
<bgpType>ebgp</bgpType> <multipathType> <multipathsNum>8</multipathsNum> </multipathType> </multipath> |
Configure maximum EBGP ECMP that can
be installed in BGP. |
<bgpRedistList>
<redistType>connected</redistType> </bgpRedistList> |
Redistribute the connected routes |
<bgpPeer>
<peerAddr>52.31.1.1</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>64902</peerAs> </bgpPeer> |
Configure BGP peer with AS 64902 and peer
address 52.31.1.1 Enable BFD for link failure detection. |
<bgpPeer>
<peerAddr>31.22.1.2</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>65503</peerAs> </bgpPeer> |
Configure BGP peer with AS 65503 and peer
address 31.22.1.2 Enable BFD for link failure detection. |
</bgp> | Close BGP tag. |
</vr> | Close namespace for the ZebOS module |
Tier-2 (Border Router)
This table shows the XML to configure IP addresses:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<interface>
<ifName>ge7</ifName> <ipAddr>53.22.1.2/24</ipAddr> </interface> <interface> <ifName>ge6</ifName> <ipAddr>31.22.1.2/24</ipAddr> </interface> <interface> <ifName>ge2</ifName> <ipAddr>23.22.1.1/24</ipAddr> </interface> |
Configure the interfaces which are connected
to the SPINE routers. This payload configures the IP address of the interface ge7, ge6 and ge2. |
</vr> | Close namespace for the ZebOS module |
This table shows the XML to configure BGP attributes:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<bgp>
<bgpAs>65503</bgpAs> |
Open BGP tag
Configure the BGP AS number. |
<multipathRelax>1</multipathRelax>
<vrfName>default</vrfName> |
Configure “as-path multipath-relax” to relax
the AS-PATH criteria for BGP ECMP |
<multipath>
<bgpType>ebgp</bgpType> <multipathType> <multipathsNum>8</multipathsNum> </multipathType> </multipath> |
Configure maximum EBGP ECMP that can be
installed in BGP. |
<bgpRedistList>
<redistType>connected</redistType> </bgpRedistList> |
Redistribute the connected routes |
<bgpPeer>
<peerAddr>53.22.1.1</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>64902</peerAs> </bgpPeer> |
Configure BGP peer with AS 64902 and peer
address 52.31.1.1 Enable BFD for link failure detection. |
<bgpPeer>
<peerAddr>31.22.1.2</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>65503</peerAs> </bgpPeer> |
Configure BGP peer with AS 65503 and peer
address 31.22.1.2 Enable BFD for link failure detection. |
<bgpPeer>
<peerAddr>23.22.1.2</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>65502</peerAs> <peerRemovePvtAs>1</peerRemovePvtAs> </bgpPeer> |
Configure BGP peer with AS 65502 and peer
address 23.22.1.2 Enable BFD for link failure detection. Configure remove-private-as for 23.22.1.2 peer |
</bgp> | Close BGP tag. |
</vr> | Close namespace for the ZebOS module |
Tier-3 (WAN Router) –Partial -Does Not Contain the Internet Configuration
This table shows the XML to configure an IP address:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<interface>
<ifName>ge1/1/1</ifName> <ipAddr>22.23.1.2/24</ipAddr> </interface> |
Configure the interfaces that are connected to
the SPINE routers. This payload configures the IP address of the interface ge1/1/1. |
</vr> | Close namespace for the ZebOS module |
This table shows the XML to configure BGP attributes:
XML Payload | Description |
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”> | Enter namespace of the ZebOS module |
<vrId>0</vrId> | Enter Vrid |
<bgp>
<bgpAs>65502</bgpAs> |
Open BGP tag
Configure the BGP AS number. |
<bgpRedistList>
<redistType>connected</redistType> </bgpRedistList> |
Redistribute the connected routes |
<bgpPeer>
<peerAddr>22.23.1.1</peerAddr> <bgpPeerBfd>1</bgpPeerBfd> <peerAs>65503</peerAs> </bgpPeer> |
Configure BGP peer with AS 64902 and peer
address 52.31.1.1 Enable BFD for link failure detection. |
</bgp> | Close BGP tag. |
</vr> | Close namespace for the ZebOS module |
Similar configurations must be repeated for all TORs, spines, cores, and border routers.
Appendix B: NetConf User Guide
This document describes managing OcNOS devices using NetConf.
This document is intended for network administrators and other engineering professionals who configure and
manage devices running OcNOS.
There are three different northbound applications in OcNOS (CLI , NetConf, and SNMP). All the northbound
applications are text-based, with each command usually associated to a specific task.
OcNOS NetConf supports transactions as described in Transactions.
NetConf Quick Start
The NetConf protocol defines a simple mechanism through which a network device can be managed, configuration information can be retrieved, and new configuration data can be uploaded.
NetConf uses a simple RPC-based mechanism to communicate between a client and a server. The client can be a script or application typically running as part of a network manager. The server is usually a network device.
A NetConf session is the logical connection between a network administrator or network configuration application
and a network device. A device must support at least one NetConf session and can support multiple sessions. Global configuration attributes can be changed during any session and the effects are visible in all sessions. The candidate and running and startup configuration are shared across all the sessions.
Note: A limited number of protocol modules are supported through NetConf. A detailed list is in the NetConf command reference.
NetConf Clients
You can use any NetConf client application to manage the device using Yang modules. These client applications require a Yang module which you downlaod from:
https://github.com/IPInfusion/OcNOS/tree/1.2
This application establishes a secure connection with the daemon running on the device to perform commands and send system responses.
There are different NetConf client applications. In this document, OpenYuma’s yangcli application is used to show NetConf operations.
Refer to the standard Yangcli operations at: https://github.com/OpenClovis/OpenYuma/blob/master/netconf/doc/yuma_docs/openyuma-yangcli-manual.odt
The NetConf operations get-config and get return large amounts of data. To improve the readability of the output, the subtree filter based sget-config and sget operations are used in this document.
Check out the git repository, compile and install OpenYuma components. Refer to the README for more details.
Download Yang files
Download the Yang files from the website:
https://github.com/IPInfusion/OcNOS/tree/1.2
Copy the files to /usr/share/yuma/modules/netconfcentral on the host machine where the client application runs. This system path only works with OpenYuma’s Yangcli client application. If you are running a different client application, follow the respective reference document to copy the Yang files to the appropriate location.
Creating User Accounts
User level access control applies to all NetConf operations. The table below describes access levels for different user types and commands to create different type of user account
Account type | Access | Command |
User | Read | username <user name> role network-user password
<password> |
Operator | All, except full configuration store
level change. |
username <user name> role network-operator password <password> |
Admin | All | username <user name> role network-admin password
<password> |
You must login into the device using network administrator account to create new user accounts. These are the steps:
[root@localhost ~]# ssh ocnos@10.12.45.253 ocnos@10.12.45.253’s password:
Last login: Wed Jun 15 21:27:39 2016
OcNOS version 1.2.0.179-OCNOS-DC-IPBASE-ZEBM IPIRouter 06/14/16 21:30:36
OcNOS>en
OcNOS#configure terminal
Enter configuration commands, one per line. End with CNTL/Z. OcNOS(config)#username netuser role network-user password Abc@6789 OcNOS(config)#username netoperator role network-operator password Abc@6789 OcNOS(config)#username netadmin role network-admin password Abc@6789
After creating the account, use the write command to write the configured data into persistent storage as
described in Copy Running Configuration to Startup
OcNOS(config)#write Building configuration… [OK]
The NetConf operations for different user account types are shown in Supported Operations.
Yangcli Operations
Establish Connection
These are the steps to establish a connection between the NetConf client and the server that is running on the device.
# yangcli server=<ip _ address> user=<user _ name> password=<password> ip _ address: Address of the device to be managed
user _ name & password: User account detail for authentication
The interactive version of this command is shown below:
# yangcli yangcli> connect
Enter string value for leaf <user> yangcli:connect> <user _ name>
Enter string value for leaf <server> yangcli:connect> <ip _ address>
Enter string value for leaf <password> yangcli:connect> <password>
Load Modules
The load command loads a YANG module into the server. This command is not part of the RFC and is only supported by the Yang client.
The ZebOS module is the parent for all protocol modules supported in OcNOS. This module includes all the sub modules. Therefore, loading this module is mandatory to start managing the device. Here is the portion of ZebOS.yang file that includes other sub modules.
module ZebOS {
namespace “https://www.ipinfusion.com/CMLSchema/ZebOS”;
prefix “ZebOS”; include nsmLACP; include oamBfd;
…
}
include bridge; include ospf; include vlan; include mstp; include layer2LACP; include bgp; include vr;
include vrf; include interface; include lldpv2; include ospf6; include rib;
include vlaninterface;
> load ZebOS
RPC Data Reply 1 for session 1:
rpc-reply {
mod-revision 2015-10-08
}
After using the load command, you can also use the mgrload command to keep the current session synchronized with the server.
> mgrload ZebOS
Load module ‘ZebOS’ OK
Configure the Device
Configuration details are placed in an XML file and sent to the netconfd server. You must refer to the Yang file to prepare the XML based configuration file with the correct hierarchy. If the hierarchy is not correct, yangcli throws an error.
One portion of the BGP protocol module Yang model is presented below. This module is a sub-module for the parent ZebOS yang module.
submodule bgp {
belongs-to ZebOS { prefix ZebOS; } include interface;
include vrf;
import cml _ data _ types { prefix cml _ data _ types;
}
revision “2015-04-25” {
description “Revised on 2015-04-25.”; }
grouping bgp-grouping { list bgp {
description “bgp”; config true;
key “bgpAs”; leaf vrId {
mandatory false; type leafref {
path “/vr/vrId”;
…
}
} // END of vrId definition.
leafkeepAlive { mandatory false;
type cml _ data _ types:CML _ UINT16 _ T { range “0..65535”;
}
default “30”; config true;
} // END of keepAlive definition.
leafholdTime { mandatory false;
type cml _ data _ types:CML _ UINT16 _ T { range “0..65535”;
…
}
default “90”; config true;
} // END of holdTime definition.
} // END of bgpDebug-grouping definition.
Based on the hierarchy in the Yang module. the following XML file named bgp.xml is created with the configuration data. The bgp.xml file is referenced in the edit-config operation specified below.
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”>
<vrId>0</vrId>
<bgp>
<bgpAs>100</bgpAs>
<keepAlive>60</keepAlive>
<holdTime>180</holdTime>
</bgp>
</vr>
Use this command to globally set or reset the keepalive and holdtime values for all the neighbors.
yangcli ocnos@10.12.45.253> edit-config config=@/root/bgp.xml Filling container /edit-config/input/target:
RPC OK Reply 15 for session 1:
Retrieve Candidate Configuration
Candidate configuration datastore is used to hold configuration data that can be manipulated without impacting the device’s current configuration. The candidate configuration is a full configuration data set that serves as a work place for creating and manipulating configuration data. Additions, deletions, and changes can be made to this data to construct the desired configuration data.
>sget-config /vr/bgp source=candidate Filling list /vr/bgp:
RPC Data Reply 1 for session 2:
rpc-reply { data {
vr {
bgp 100 {
bgpAs 100
holdTime 180
keepAlive 60 vrfName default
}
}
}
}
Commit Candidate Configuration
A <commit> operation MAY be performed at any time that causes the device’s running configuration to be set to the value of the candidate configuration.
yangcli ocnos@10.12.45.253> commit RPC OK Reply 16 for session 1:
Retrieve Running Configuration
Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state. You can use the get-config operation to fetch the running configuration data.
>sget-config /vr/bgp source=running Filling list /vr/bgp:
RPC Data Reply 1 for session 2:
rpc-reply { data {
vr {
bgp 100 {
bgpAs 100
holdTime 180
keepAlive 60 vrfName default
}
}
}
}
Retrieve Running Configuration and State Data
State data is the additional data on a system that is not configuration data such as read-only status information and collected statistics. You can use the get operation to fetch a protocol module’s running configuration and state data.
>sget /vr/bgp rpc-reply {
data { vr {
bgp 100 {
bgpAs 100
holdTime 180
keepAlive 60 vrfName default bgpTableVersion 0
ntwkPrefixCount 0
ibgpMetric 0
pathAttrBest 0 clusterList fill _ value
routerRunIpAddr fill _ value bgpShowTypeStr fill _ value bgpShowType 0
rfdMaxPenaltyCeil 0
rfdMinPenaltyFloor 0
dampeningStr 0
rfdCbStr 0
ibgpMetric 0
}
}
}
}
Copy Running Configuration to Startup
NetConf supports startup options, so if you have configured the device and want to retain the configuration after a device reboot, copy the running configuration into startup configuration. The yangcli command is:
> copy-config source=running target=startup The equivalent OcNOS command is
# write
Error Messages
NetConf operations return protocol, management layer, and protocol module errors. The example below depicts an error returned by a protocol module.
Copy the content below into bgp_err.xml.
<vr xmlns=”https://www.ipinfusion.com/CMLSchema/ZebOS”>
<vrId>0</vrId>
<bgp>
<bgpAs>1</bgpAs>
<keepAlive>300</keepAlive>
<holdTime>200</holdTime>
</bgp>
</vr>
Execute the following command and commit the changes
yangcli tbyran@10.12.45.253> edit-config config=@/root/bgp _ err.xml Filling container /edit-config/input/target:
RPC OK Reply 12 for session 1: yangcli tbyran@10.12.45.253> commit
mgr _ rpc: got invalid reply on session 1 (invalid XPath expression syntax) RPC Error Reply 13 for session 1:
rpc-reply { rpc-error {
error-type protocol error-tag
error-severity warning
error-app-tag general-warning error-path ‘RPC operation failed’
error-message ‘%% Hold time should be greater than the keepalive time’ error-info {
error-number 4294962411
}
}
}
Transactions
OcNOS supports transaction-oriented configuration management. Transactions are created implicitly by edit- config operations; commit and discard-changes operations close or terminate the transactions. Successive edit-config operations are placed in the same transaction.
Discard Changes
Discard the transaction or candidate configuration changes.
yangcli ocnos@10.12.45.253> sget-config /vr/ospf source=candidate Filling list /vr/ospf:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 14 for session 2:
rpc-reply { data {
vr {
ospf 0 {
ospfProcessId 0 ospfShutDown true
}
ospf 200 {
ospfProcessId 200
}
}
}
}
yangcli ocnos@10.12.45.253> discard-changes RPC OK Reply 15 for session 2:
yangcli ocnos@10.12.45.253> sget-config /vr/ospf source=candidate Filling list /vr/ospf:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 16 for session 2:
rpc-reply { data {
vr {
ospf 0 {
ospfProcessId 0 ospfShutDown true
}
}
}
}
Commit
Commit the transaction or candidate configuration changes.
yangcli ocnos@10.12.45.253> create /vr/ospf
Filling list /vr/ospf:
Filling key leaf /vr/ospf/ospfProcessId: Enter int32 value for leaf <ospfProcessId> yangcli ocnos@10.12.45.253:create> 500
Filling key leaf /vr/vrId:
Enter uint32 value for leaf <vrId> yangcli ocnos@10.12.45.253> 0
RPC OK Reply 17 for session 2: yangcli ocnos@10.12.45.253> commit RPC OK Reply 18 for session 2:
yangcli ocnos@10.12.45.253> sget-config /vr/ospf source=running Filling list /vr/ospf:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 19 for session 2:
rpc-reply { data {
vr {
ospf 0 {
ospfProcessId 0 ospfShutDown true
}
ospf 500 {
ospfProcessId 500
}
}
}
}
Save Point
OcNOS supports the savepoint feature. A savepoint is a snapshot of the device current state. You can switch the device state to any savepoint at any time.
This example creates two savepoints HT180 and HT300
- HT180has holdTime set to 180
- HT300has holdTime set to 300
yangcli ocnos@10.12.45.253> create
create create-savepoint create-subscription yangcli ocnos@10.12.45.253> create-savepoint
Enter string value for leaf <savepointName> yangcli ocnos@10.12.45.253:create-savepoint> HT180
RPC OK Reply 4 for session 2:
yangcli ocnos@10.12.45.253> edit-config config=@/root/bgp _ ht.xml Filling container /edit-config/input/target:
RPC OK Reply 5 for session 2: yangcli ocnos@10.12.45.253> commit RPC OK Reply 6 for session 2:
yangcli ocnos@10.12.45.253> sget-config /vr/bgp source=running
Filling list /vr/bgp:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 7 for session 2:
rpc-reply { data {
vr {
bgp 100 {
bgpAs 100
holdTime 300
keepAlive 60
vrfName default
}
}
}
}
yangcli ocnos@10.12.45.253> create-savepoint HT300 RPC OK Reply 8 for session 2:
Roll Back
This example shows rolling back the configuration. First, notice the current value of the holdTime attribute:
yangcli ocnos@10.12.45.253> sget-config /vr/bgp source=running
Filling list /vr/bgp:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 10 for session 2:
rpc-reply { data {
vr {
bgp 100 {
bgpAs 100
holdTime 180
keepAlive 60 vrfName default
}
}
}
}
Now roll back to savepoint HT300 and note the value of holdTime attribute.
yangcli ocnos@10.12.45.253> rollback-transaction HT300 RPC OK Reply 11 for session 2:
yangcli ocnos@10.12.45.253> sget-config /vr/bgp source=running
Filling list /vr/bgp:
mgr _ rpc: got invalid reply on session 1 (missing index component) RPC Data Reply 12 for session 2:
rpc-reply { data {
vr {
bgp 100 {
bgpAs 100
holdTime 300
keepAlive 60 vrfName default
}
}
}
}
Supported Operations
All the NetConf operations are captured based on the capability. Hence, any operation falling in multiple
capability are documented separately.
Note: Capability “base:1.0” supports candidate and running configuration store.
Capability | Operation | User Role | Supported (Yes/No) | Comments |
:base:1.0 | <get> | User, Operator, Admin | Yes | |
:base:1.0 | <get> with subtree filter | User, Operator, Admin | Yes | |
:base:1.0 | <get-config> | User, Operator, Admin | Yes | |
:base:1.0 | get-config source=<target> | User, Operator, Admin | Yes | |
:base:1.0 | <get-config> with subtreefilter | User, Operator, Admin | Yes | |
:base:1.0 | <edit-config> <target> as parameter | Operator, Admin | Yes | Running configuration as target is not supported because writtable- running capability is not supported |
:base:1.0 | <edit-config> <config> as parameter | Operator, Admin | Yes | |
:base:1.0 | <edit-config>:
<merge> |
Operator, Admin | Yes | |
:base:1.0 | <edit-config>:
<replace> |
Operator, Admin | Yes | |
:base:1.0 | <edit-config>:
<create> |
Operator, Admin | Yes | |
:base:1.0 | <edit-config>:
<delete> |
Operator, Admin | Yes | |
:base:1.0 | <edit-config>:
<remove> |
Operator, Admin | Yes | |
Capability | Operation | User Role | Supported (Yes/No) | Comments |
:base:1.0 | <edit-config>: <none> | Operator, Admin | Yes | |
:base:1.0 | <edit-config>: <error- option > as stop-on- error | Operator, Admin | No | |
:base:1.0 | <edit-config>: <error- option > as continue- on-error | Operator, Admin | No |
:rollback-on- error:1.0 | <edit-config>: <error- option > as rollback- on-error | Operator, Admin | Partial | By default, this is the behavior. So there is no need to pass this error- option. |
:validate: 1.1 | <edit-config>: <test- option > | Operator, Admin | No | By default configuration entries are validated and stored, hence
this operation and its parameters are not handled. External configuration store validation is not supported (i.e URL). |
:base:1.0 | <copy-config> : < target> <source> | Operator, Admin | Yes | |
:base:1.0 | <lock> : < target> | Operator, Admin | Yes | Candidate configuration
lock is not supported. |
:base:1.0 | <unlock> : < target> | Operator, Admin | Yes | Candidate configuration
unlock is not supported |
:base:1.0 | <close-session> close current session | User, Operator, Admin | Yes | |
:base:1.0 | <kill-session> : Close other session | User, Operator, Admin | Yes | |
:base:1.0 | subtreefiltering | User, Operator, Admin | Yes | |
:Startup:1.0 | get-config
<source=startup> |
User, Operator, Admin | Yes | |
:Startup:1.0 | copy-config
<source=startup> |
Admin | No | |
:Startup:1.0 | copy-config
<target=startup> |
Admin | Partial | Running to startup copy is supported. |
:Startup:1.0 | lock <startup> | Admin | Yes | |
:Startup:1.0 | unlock <startup> | Admin | Yes | |
Capability | Operation | User Role | Supported (Yes/No) | Comments |
:Startup:1.0 | validate
<source=startup> |
Admin | No | Always configuration entries are validated and stored, but external configuration store validation is not supported. |
:Startup:1.0 | delete-config | Admin | Yes |
:url:1.0 | URL capability | User, Operator, Admin | No | Not supported |
:with-defaults | <get> | User, Operator, Admin | Partial | By default, “report-all” functionality is supported when with-default
option is passed. Other options (explicit, tagged, explicit-tagged) are not supported |
:with-defaults | <get-config> | User, Operator, Admin | Partial | By default, “report-all” functionality is supported when with-default
option is passed. Other options (explicit, tagged, explicit-tagged) are not supported |
:confirmed- commit | <commit> <confirmed> | Operator, Admin | Yes | |
:confirmed- commit | <commit> <confirmed>
<persist> |
Operator, Admin | Yes |