This XML configuration snippet is used to initiate a BGP process with the specified autonomous system number and router ID.

This configuration was introduced in OcNOS version 4.2.

Here is the sample OpenConfig NetConf Payload for configuring a BGP process within a network instance. It sets the BGP autonomous system number (AS) and specifies the router ID.

The below CLI commands are used to configure a BGP process with the AS number and set the BGP router ID.

Here is a sample OcNOS NetConf Payload used to configure a network instance with the name and type. It also configures a BGP instance with an AS number and sets the BGP router ID.

Here is a NetConf validation response that provides information about the enabled state and identifiers, as well as details about the BGP global configuration, including the AS number and router ID.

 

 

On OpenConfig BGP datamodel the container global do not have any key to identify a single BGP instance, but the BGP AS information is placed under xpath /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/global/config/as.

On IPI BGP datamodel the BGP AS information is a key for BGP container, and it does not allow the delete on xpath /ipi-bgp:/bgp/bgp-instances/bgp-instance/config/bgp-as to avoid delete its own instance key.

In this case, when translation framework detects a delete or remove operation on following OpenConfig xpaths:

It will trigger an error message to NETCONF client and do not execute the delete operation.

To avoid this issue, when user needs to delete or remove a configuration under OpenConfig xpath /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/global/config, user must adds a "delete" or "remove" operation directly on the leaf or leaves desired to be removed, rather than delete the entire container.

This XML configuration snippet is used to set up BGP Global configuration with default VRF.

This configuration was introduced in OcNOS version 6.2.0.

Here is the sample OpenConfig NetConf Payload to define BGP settings for the default network instance, including global BGP parameters, neighbor configurations, and address family tables.

Ensure that the AFI-SAFI container is present in the applied configuration to facilitate the configuration of address families.

The below CLI commands are used to configure BGP settings for a specified AS number on a networking device. They define critical attributes of the BGP process, including the router ID, confederation settings, best path selection criteria, graceful restart behavior, and neighbor configuration. Additionally, the commands enable support for IPv4 unicast address families and specify advanced options like additional path handling and maximum path selection for internal BGP peers. The neighbor statement establishes a BGP neighbor relationship with an adjacent router using the IP address and assigns it to a specified AS number.

Here is a sample OcNOS NetConf Payload for configuring BGP settings on a network device. It defines a BGP instance with AS number and sets its router ID, graceful restart parameters, route selection options, and address family settings. Specifically, it configures BGP to operate with IPv4 unicast address families, allowing for the exchange of IPv4 unicast routing information. Additionally, the payload specifies additional path handling, maximum path selection for internal BGP peers, and establishes a BGP neighbor relationship with an adjacent router using the IP address.

Here is a NetConf validation response indicates the successful validation of a network configuration specified in a NetConf payload. In this specific response, it verifies the correctness of the configuration for a specified network instance with associated protocols and interfaces. The validation ensures that the configuration adheres to the defined network instance types, policy types, and address families. All relevant elements, such as the BGP instance, its parameters, and the associated interfaces, are validated against the specified OpenConfig model.

This XML configuration snippet uses the payloads provided in this section to configure BGP Global with user-defined VRF data from the Open Config perspective.

This configuration was introduced in OcNOS version 6.2.0.

Here is the sample OpenConfig NetConf Payload used to configure network instances with BGP Global settings. This payload includes configuration for both the default network instance and a custom network instance named red.

In the default instance, BGP Global settings such as the AS number, router ID, route selection options, and graceful restart parameters are configured.

In the red network instance, in addition to the common BGP Global settings, specific AFI-SAFI settings are configured, including the number of maximum paths for both eBGP and iBGP. This example demonstrates how the payload can be adapted to configure different network instances with unique BGP configurations.

The below CLI commands are used to configure an IP VRF with a route distinguisher. In addition, the router BGP is configured with various BGP settings, including router ID, bestpath options, graceful restart parameters, and confederation settings. Inside the address-family IPv4 VRF context, the maximum paths for eBGP and iBGP are set. The BGP confederation is also configured with an identifier and peers.

Here is a sample OcNOS NetConf Payload to configure a BGP instance with AS number, a router ID, and settings to ignore AIGP for bestpath selection. It also includes graceful restart parameters with a restart time and a stale path max retention time. Additionally, the payload configures route selection options to ignore AS path length and perform external comparisons based on router IDs. Inside the address-family VRF context for IPv4 unicast, it sets the confederation identifier and the peer AS number. Maximum path settings are configured for both eBGP and iBGP paths.

Here is a NetConf validation response for configuring settings for the default network instance and a network instance. It also includes configurations for protocols, under network instances. Additionally, there are table configurations for IPv4 and IPv6 address families.

This XML configuration snippet is used to configure neighbors in non-default VRF of BGP.

This configuration was introduced in OcNOS version 4.2.

Here is the sample OpenConfig NetConf Payload to configure network instances, specifically two instances: default and VRF1. It also configures BGP settings within these network instances, including neighbors and address families. Additionally, it configures tables for IPv4 and IPv6 address families within the network instances.

The below CLI commands are used to configure a BGP setup with two address families: global ipv4 unicast and ipv4 vrf VRF1. It includes various neighbor configurations, prefix limits, route maps, and other BGP parameters to control BGP behavior in both the global and VRF contexts.

Here is a sample OcNOS NetConf Payload to configure BGP settings with VRF support and address-families in an OcNOS network device using the IPI YANG models. It defines BGP peering relationships, specify BGP attributes, and apply route maps within the context of both the global BGP instance and the VRF VRF1.

Here is a NetConf validation response to configure payload for BGP settings in a network instance, including global BGP settings and BGP neighbors.

This XML configuration snippet defines the eBGP neighbor with a Time-to-Live (TTL) value.

This configuration was introduced in OcNOS version 4.2.

Here is the sample OpenConfig NetConf Payload that defines a network instance named VRF1 with various configurations, including the route distinguisher, protocols, and tables. Specifically, it sets up BGP protocol with a global AS number and a neighbor with an AS number. The ebgp-multihop feature is enabled for this neighbor with a TTL value.

Additionally, the payload defines three tables, one for directly connected IPv4 routes, one for directly connected IPv6 routes, and one for BGP IPv4 routes.

The below CLI commands are used to configure a BGP neighbor relationship in the VRF1, allowing the BGP router with AS number 100 to communicate with a neighbor at IP address 1.1.1.2, which has AS number 200, and the configuration ensures that the session can be established even if the TTL is set to a higher value, in this case, 20.

Here is a sample OcNOS NetConf Payload that defines a VRF instance named VRF1 with the associated BGP settings. The VRF is set to use IPv4 unicast address-family. Within this VRF, a BGP peering session is established with a remote neighbor having the IP address 1.1.1.2 and AS number 200. To ensure the BGP session can be established, the ebgp-multihop feature is enabled with a maximum hop count of 20, allowing the BGP router to communicate with a neighbor that might be multiple hops away. The BGP configuration also specifies a route distinguisher (RD) of 1.2.3.4:56 for the VRF. This configuration is essential for routing and forwarding traffic within the VRF while maintaining isolation from other VRFs or the global routing table.

Here is a NetConf validation response for the network instance VRF1 and its associated BGP settings indicates that the provided configuration is compliant with the expected structure and format defined in the YANG data model for network instances and BGP protocols. This validation response affirms that there are no errors or inconsistencies in the configuration, affirming its readiness for application to the network device. It verifies that the specified parameters, such as route distinguisher, autonomous system numbers, and address families, are correctly defined and align with the defined standards, ensuring smooth and accurate operation within the network infrastructure.

This XML configuration snippet is used to specify that BGP peer-groups should be created within the default VRF.

This configuration was introduced in OcNOS version 5.1.

Here is the sample OpenConfig NetConf Payload to configure BGP settings within the default network instance. It defines various BGP parameters and peer groups for the specified AFI-SAFI combinations, including IPv4 unicast, IPv4 labeled unicast, IPv6 labeled unicast, and L3VPN IPv6 unicast. This configuration includes authentication passwords, timers, route reflector settings, and more for different peer groups such as ABC, peer1, and peer2.

The below CLI commands configure various BGP parameters and policies for different neighbors and address families within AS number 100.

Here is a sample OcNOS NetConf Payload to set up BGP peering and routing policies within the given AS number (100) and defines parameters for various address families and peer groups.

Here is a NetConf validation response that defines several aspects of BGP, including global BGP configuration, peer groups, and AFI-SAFIs for different address families. The configuration also includes authentication settings, timers, transport settings, and route reflection.

This XML configuration snippet is used to configure BGP Peer-groups with user-defined VRFs.

This configuration was introduced in OcNOS version 5.1.

Here is the sample OpenConfig NetConf Payload that provides a structured representation of the settings for various BGP configurations, such as Autonomous System (AS) numbers, Address Family Identifier and Subsequent Address Family Identifier (AFI-SAFI) settings, authentication, timers, and more.

The below CLI commands are used to setup the VRF instances and BGP settings within a network infrastructure. VRFs allow for the segmentation of the network, enabling the isolation of routing domains. In this configuration, two VRFs, named vrfA and vrfB, are defined with unique Route Distinguisher (RD) values, indicating their separation.

Within the BGP configuration, specific address families for IPv4 and IPv6 are defined, each associated with a corresponding VRF. Peer-groups, neighbors, authentication keys, timers, and various other BGP parameters are configured to facilitate routing and peering relationships in the network.

Here is a sample OcNOS NetConf Payload that illustrates a comprehensive BGP configuration. The configuration is divided into specific sections, each addressing different aspects of BGP operation, security, and peering.

Within this payload, two distinct AFI and SAFI contexts are defined for IPv4 and IPv6 in separate VRF instances named vrfA and vrfB. Each VRF is associated with specific BGP peer groups, peers, and a range of configurations that dictate the behavior of BGP in these contexts.

The configuration also includes authentication keys, prefix limits, timers, route reflection settings, BFD configuration, and other essential parameters that ensure the proper functioning of BGP in the specified VRFs.

Here is a NetConf validation response that specifies different network instances, including the default, management, vrfA, and vrfB instances.

After the initial configuration of /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/peer-groups and /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/neighbors paths on the equipment, subsequent configurations on those paths do not require specifying the AFI-SAFI. The translation process will automatically retrieve this information from the equipment database, simplifying the configuration process for the user.

This XML configuration snippet is used to specify the configuration of the update-source parameter on a neighbor in the context of a network device configuration.

This configuration was introduced in OcNOS version 5.0.

Here is the sample OpenConfig NetConf Payload that specifies the configuration of a network instance named default with BGP. Within this network instance, a BGP peer or neighbor is configured to establish a connection with the IP address 1.1.1.1 and share IPv4 unicast routing information.

In this payload, various parameters such as the local address, peer AS, and AFI-SAFI are configured to enable communication and routing between BGP neighbors.

This XML configuration allows internal BGP sessions to use any available operating interface for establishing TCP connections.

The below CLI commands are to configure a BGP neighbor relationship within the BGP process running on a router with AS number 100. Specifically, it configures a BGP neighbor with the IP address 1.1.1.1, assigns it the same AS number (AS 100), and specifies that the local address for establishing the BGP connection should be 2.2.2.2. This update-source parameter ensures that the BGP sessions between the local router and the neighbor use the specified source IP address (2.2.2.2) for their TCP connections.

Here is a sample OcNOS NetConf Payload for a BGP instance with AS number 100 is defined. Within this instance, a BGP peer relationship is established with a neighbor having the IP address 1.1.1.1. The payload further specifies that the local router should use the source IP address 2.2.2.2 when communicating with this BGP peer, ensuring proper BGP session establishment and communication.

Here is a NetConf validation response describing the default network instance, along with its associated protocols. Notably, the response includes information about a BGP instance with an AS number of 100, illustrating its global and neighbor-specific settings. The BGP neighbor relationship is established with an IP address of 1.1.1.1 and is configured to use a local address of 2.2.2.2 for communication.

None

In this XML configuration snippet, two links are used to ensure service availability, and all traffic is routed through both links simultaneously. If either of these links experiences a failure, all traffic is automatically redirected to the remaining available link.

This configuration was introduced in OcNOS version 5.1.

Here is the sample OpenConfig NetConf Payload to indicate the configuration of a network instance named TEST_A9 with associated BGP protocols and peer groups. In this scenario, two peer groups, PPAL_BGP_L3 and BCK_BGP_L3, are defined within BGP, each with its specific settings. The configuration also specifies the use of multiple paths for external BGP (eBGP) sessions and enables IPv4 unicast address families for these peer groups. Furthermore, it outlines neighbor configurations, including their addresses, peer group associations, and additional parameters like local and peer AS numbers.

The below CLI commands are used to create a specific VRF instance named TEST_A9 with a unique route distinguisher (RD) of 65000:100. Within the BGP configuration for AS number 65000, two address families, IPv4 and IPv6, are defined for the TEST_A9 VRF, each allowing up to two paths for eBGP (external BGP) sessions.

The configuration also includes the setup of neighbor relationships, with peers grouped into PPAL_BGP_L3 and BCK_BGP_L3 peer groups. Each neighbor is associated with the appropriate peer group, and their remote AS numbers and descriptions are specified.

Here is a sample OcNOS NetConf Payload illustrating the configuration of a network instance with associated BGP settings. This configuration is designed to establish BGP sessions within the specified VRF instance and configure BGP-related parameters.

In this payload, the VRF instance type, BGP AS, BGP peering configurations for both IPv4 and IPv6 address families, and the maximum number of paths allowed for eBGP (external BGP) sessions are configured.

Here is a NetConf validation response about the network instance's configuration, the BGP AS number, BGP peering details, and protocol tables for both IPv4 and IPv6 address families.

In this XML configuration snippet, BGP instances are configured on network-instance on OpenConfig and on container BGP on OcNos side. Due this difference the delete process need to handle if the operation is trying to delete one VRF instance or the entire BGP instance.

When using OpenConfig, the BGP object on OcNOS database is only deleted by the delete on "default" network-instance. When the delete is execute on VRF network-instance it only deletes the given VRF instance.

If there are VRF instances configured and a delete operation is executed on "default" network-instance, it going to clean only entries configured on "default" network-instance. To remove VRF instances, the user needs to apply a operation delete on VRF instances.

This configuration was introduced in OcNOS version 5.1.

Delete default instance:

Delete VRF instance:

Delete default instance:

On OpenConfig BGP datamodel the container global do not have any key to identify a single BGP instance, but the BGP AS information is placed under xpath /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/global/config/as.

On IPI BGP datamodel the BGP AS information is a key for BGP container, and it does not allow the delete on xpath /ipi-bgp:/bgp/bgp-instances/bgp-instance/config/bgp-as to avoid delete its own instance key.

In this case, when translation framework detects a delete or remove operation on following OpenConfig xpaths:

It will trigger an error message to NETCONF client and do not execute the delete operation.

To avoid this issue, when user needs to delete or remove a configuration under OpenConfig xpath /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/global/config, user must adds a "delete" or "remove" operation directly on the leaf or leaves desired to be removed, rather than delete the entire container.

In this XML configuration snippet, the BGP RIB (Routing information base) is a set of counters to retrieve information about routes from neighbors. In this chapter will be discussed about BGP RIB IPv4.

The containers related to RIB are status only on both Open Config and OcNOS datamodels, and there are no configuration related to this.

On OcNOS the containers are available only after the BGP negotiate routers, before it this tables are empty and could not be retrieved.

The table below show which information each table displays.

This configuration was introduced in OcNOS version 6.2.

N/A

The config below is just an example to illustrate to counters indicated.

To have a complete BGP RIB scenario it needs more than one equipment configured to work with BGP.

The containers related to RIB are status only on both Open Config and OcNOS datamodels, and there are no configuration related to this.

On OcNOS the containers are available only after the BGP negotiate routers, before it this tables are empty and could not be retrieved.

The paths /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/rib/afi-safi/afi-safi/ipv4-unicast/loc-rib/routes/route and /oc-netinst:network-instances/network-instance/protocols/protocol/bgp/rib/afi-safi/afi-safi/ipv6-unicast/loc-rib/routes/route have some keys with fixed values, the table below show the values. Note the “X” indicate that is valid for IPv4 and IPv6 containers.

 

In this XML configuration snippet, the BGP RIB (Routing information base) is a set of counters to retrieve information about routes from neighbors. In this chapter will be discussed about BGP RIB IPv6.

The containers related to RIB are status only on both Open Config and OcNOS datamodels, and there are no configuration related to this.

On OcNOS the containers are available only after the BGP negotiate routers, before it this tables are empty and could not be retrieved.

The table below show which information each table displays.

This configuration was introduced in OcNOS version 6.2.

The config below is just an example to illustrate to counters indicated.

To have a complete BGP RIB scenario it needs more than one equipment configured to work with BGP.