IP Connectivity by using BGP data


Starting with BMC Helix Discovery version 25.2 (on-premises) and 25.2.02 (SaaS), support for discovering relationships based on Border Gateway Protocol (BGP) data is added. Also, a new node kind, NetworkRoutingGroup, and a new visualization are introduced. The IP connectivity that uses BGP data feature aims to discover IP links between network devices by leveraging BGP routing data.

Supported Discovery versions

All Discovery versions starting with BMC Discovery 25.2 (15.0) are supported.

Prerequisites

Valid SNMP credentials are required to discover IP links between network devices.

What is Border Gateway Protocol?

Border Gateway Protocol (BGP) is a basic routing protocol for the internet. It facilitates routers to exchange information about network paths and reachability, determining the best route for data packets to travel across networks. BGP facilitates peering between autonomous systems (ASes), which are distinct networks managed by a single organization. Each AS is uniquely identified by Autonomous System Number (ASN). Network administrators configure BGP with rules and policies to guide routing decisions. BGP enhances network stability by quickly adapting to network failures and finding alternative routes when a path becomes unavailable.

To exchange BGP routing data, devices establish BGP peering sessions by using devices' IP addresses.

How Border Gateway Protocol works

As an example, consider two locations or sites, each equipped with a pair of devices. Within each location, the devices reside in the same BGP Autonomous System (AS) and form BGP peerings to exchange routing information. Inter-site connectivity is established as follows:

Device A at the first location maintains a BGP peering with an upstream ISP Customer Premises Equipment (CPE) device, the details of which are not accessible to us. Similarly, Device C at the second location has a BGP peering with its local ISP CPE device, which is also undiscoverable. Traffic originating from the first location traverses Device A, then passes through the intermediary ISP network through the CPE devices, across the public internet, and ultimately reaches Device C at the second location. At the first location, Device B serves as a backup route for inter-site communication. It connects to a secondary ISP CPE and maintains a BGP route towards Device D at the second location.

The following diagram shows a visual representation of the setup:

BGP-Model-Page-8.drawio.png

The BGP routing entry for traffic from Device A (Site 1) to Device C (Site 2) is as follows:

Network             Next Hop          BGP AS Path
192.169.2.1/32      192.168.1.2       6666 65115

This means that to reach 192.169.2.1 (Device C), the next hop is 192.168.1.2 (an ISP device), and the path involves ASNs 6666 and 65115.

Conversely, the routing table on Device C for reaching Device A would look as follows:

Network             Next Hop          BGP AS Path
192.168.1.1/32      192.169.2.2       6666 65111

Consequently, analyzing BGP routing tables enables us to understand and model IP connectivity between devices across different sites.

How to enable IP connectivity by using Border Gateway Protocol data

To start discovering IP links between network devices by leveraging BGP routing data, on the appliance, enable the IP Logical Connectivity from the IP Network view, as shown in the following screenshot. For more information, see the official BMC Helix Discovery documentation.

IP Logical Connectivity.png

Discovery model

The BGP pattern is triggered by a NetworkDevice with the __bgp_asn attribute defined. Then, by using Simple Network Management Protocol (SNMP), the pattern retrieves data from the BGP routing table (BGP4-MIB::BGP4PathAttrTable 1.3.6.1.2.1.15.6) on that device and creates nodes and relationships to represent the network layer 3 connectivity.

In this example of the setup with two sites, the BMC Discovery model will be as follows:

BGP-Model-Page-7.drawio (1).png

The Discovery model will consist of the following elements:

  • NetworkRoutingGroup Node—Represents a BGP Autonomous System (AS). Network devices within this AS are connected to this node through a NetworkDevice:Member:Collection:Collection:Member:NetworkRoutingGroup relationship.
  • NetworkLink Relationship—Indicates a direct BGP peering connection between two discovered IP addresses. This connection shown as IPAddress:Peer:NetworkLink:Peer:IPAddress.
  • ExternalNetworkLink Relationship can represent the following:
    • Local IPAddress to external IPAddress—A link between an IP address within the data center (DC) and a peering IP address on the internet (IPAddress:Peer:ExternalNetworkLink:Peer:IPAddress).
    • AS to AS—A link between different Autonomous Systems found in the BGP AS path (NetworkRoutingGroup:Peer:ExternalNetworkLink:Peer:NetworkRoutingGroup).
  • LogicalNetworkLink Relationship—Represents a shortcut between two IP addresses, where the actual network path involves one or more intermediary AS NetworkRoutingGroup nodes (IPAddress:Peer:LogicalNetworkLink:Peer:IPAddress).
  • IPAddress::DeviceAddress:DeviceWithAddress:NetworkRoutingGroup Relationship—Links an IP address on the internet to the specific AS it belongs to.
Important

The BGP pattern requests the BGP4PathAttrTable only from devices with the number of valid routes lower than the configured routes_processing_limit. To determine the valid route count for a device, a query is sent for IP-FORWARD-MIB::inetCidrRouteNumber (.3.6.1.2.1.4.24.6.0) or IP-FORWARD-MIB::ipCidrRouteNumber (1.3.6.1.2.1.4.24.3.0).

Config.png

To display BGP retrieved data, BMC Discovery provides the following visualizations:

  • IP Logical Connectivity — This visualization shows direct shortcut relationships between IP addresses, which gives a quick understanding of IP connectivity without the need for detailed AS Path information.

LogicalIPConnectivity.png

  • IP Connectivity — This visualization shows BGP Network Routing Groups and AS Path details.

IPConnectivity.png

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*