Examples for SSF.OS.BGP4

Disclaimer

This implementation of BGP-4 is constantly evolving, and examples are not always immediately updated to reflect the most current version. It is not always safe to assume that an example still runs properly. In addition, the DML files and the output files may look different than the way there are described in some of the accompanying documentation.

Summary of Examples

BGP Debugging Output Conventions

Many of the examples refer to debugging output messages. In such messages, each line of output has the same format. The first value on a line is a floating point number which is the simulation time at which the message was printed. The second value identifies the BGP instance to which the message applies. It is a string of the form bgp@<nh>, where <nh> is the NHI prefix address (or NH (Network-Host) address) of the router where that BGP instance is located. Each BGP instance has a unique NHI prefix address. Following this identification string is an arbitrary string which describes something relevant to the BGP instance. For example, it may describe an event that took place, an error condition, or attributes which apply to the BGP instance. It is somewhat free-form. (There are some exceptions to this output format. The typical exceptions are multi-line debugging output messages. For example, when the contents of a forwarding table are printed, the first printed line adheres to these conventions and indicates that following it will be the output of the table. One line is printed per table entry, and each is indented with spaces, but contains no simulation time or NHI prefix address values.) In some of the examples, an additional value has been added to the beginning of each line to indicate the line number.

In most examples, it is useful to keep track of which autonomous system each BGP instance is a member. Each AS in a simulation is associated with a unique NHI prefix address (which looks like the NHI prefix addresses of hosts and routers, except that a Net construct is indicated, and not a host or router construct). Instead of assigning them arbitrary numbers, each AS is referred to by its AS NHI prefix address. Turning on the show_id_data option (by giving it a value of true) in the simulation's DML causes the mapping between BGP NHI prefix addresses and AS NHI prefix addresses to be printed at the beginning of the simulation. One line per BGP instance is printed. All BGP instances within the same AS share a unique string prefix (not to be confused with an address prefix) among their NHI address prefixes. However, there is no simple rule to determine what that prefix is. The easiest way to find the prefix is by visually inspecting the mapping of BGP NHI address prefixes to AS address prefixes. The string prefix will almost always be obvious.

References and Related Resources

   [1]  RFC1771: A Border Gateway Protocol 4 (BGP-4)

   [2]  RFC1557: Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2

   [3]  RFC1772: Application of the Border Gateway Protocol in the Internet

   [4]  RFC1773: Experience with the BGP-4 protocol

   [5]  RFC1774: BGP-4 Protocol Analysis

   [6]  RFC2796: BGP Route Reflection - An Alternative to Full Mesh IBGP

   [7]  BGP4: Inter-Domain Routing in the Internet by John W. Stewart III

   [8]  Internet Routing Architectures by Bassam Halabi