Disclaimer
This implementation of BGP-4 is constantly improving and evolving, and
examples are not always immediately updated to reflect the most
current version. It is usually (though not always) safe to assume
that an example still runs properly, but the DML files and the output
files may look different than the way there are described in some of
the accompanying documentation.
Compatibility
This example is up-to-date with SSF.OS.BGP4 version 1.1.0.
Conventions
For an explanation of
the debugging output used in this example, refer to BGP Debugging Output Conventions.
Overview
This example shows how a BGP speaker propagates routes that it learns
to other BGP speakers who may not know of these routes yet.
Files
primary source: propagation.dml
library source: dictionary.dml
schema source: net.dml
raw output: propagation.out
Running
To run this example, SSFNet must be installed and the three source
files, as listed in the previous subsection, must be accessible. As
an example, if the three source files were together in the same
directory, the following command could be used to run the
simulation:
java SSF.Net.Net 1 propagation.dml dictionary.dml net.dml
Network Graph
Discussion
In this very simple example, there are three ASes connected in a line.
(AS 1 connects to AS 2, and AS 2 connects to AS 3.) We trace how the
route advertised by AS 1 finds its way through AS 2 and into AS 3's
routing information base. The configuration file propagation.dml was used. (It may
be useful at this point to open that file in a separate window.)
The output produced by running with this DML file as input is:
001> 0.0 bgp@0:0 AS 3 id 0.0.0.17/32 prefix 0.0.0.16/29 002> 0.0 bgp@1:0 AS 2 id 0.0.0.9/32 prefix 0.0.0.8/29 003> 0.0 bgp@2:0 AS 1 id 0.0.0.1/32 prefix 0.0.0.0/29 004> 5.52E-4 bgp@2:0 snd update advertising my AS to bgp@1:0 rte=0.0.0.0/29 005> 5.52E-4 bgp@0:0 snd update advertising my AS to bgp@1:0 rte=0.0.0.16/29 006> 5.52E-4 bgp@1:0 snd update advertising my AS to bgp@0:0 rte=0.0.0.8/29 007> 5.52E-4 bgp@1:0 snd update advertising my AS to bgp@2:0 rte=0.0.0.8/29 008> 6.83E-4 bgp@2:0 rcv update frm bgp@1:0 rte=0.0.0.8/29 009> 6.83E-4 bgp@1:0 rcv update frm bgp@2:0 rte=0.0.0.0/29 010> 6.83E-4 bgp@1:0 snd update to bgp@0:0 rte=0.0.0.0/29 011> 6.83E-4 bgp@0:0 rcv update frm bgp@1:0 rte=0.0.0.8/29 012> 6.83E-4 bgp@1:0 rcv update frm bgp@0:0 rte=0.0.0.16/29 013> 6.83E-4 bgp@1:0 snd update to bgp@2:0 rte=0.0.0.16/29 014> 8.14E-4 bgp@0:0 rcv update frm bgp@1:0 rte=0.0.0.0/29 015> 8.44E-4 bgp@2:0 rcv update frm bgp@1:0 rte=0.0.0.16/29 |
In line 4, we see that the BGP speaker at AS 1 advertises the routing information for its AS to its peer in AS 2. This update is received by the BGP speaker at AS 2 in line 9 and forwarded to AS 3 in line 10. The speaker at AS 3 receives this update in line 14, but does not forward it anywhere as there are no peers who might not already know of it.