Simulation Engine

Home

Tutorial

SimulationEngine

A SimulationEngine in BGPy takes as input an AS graph as an attribute, and controls the propagation of announcements. You can see the Base class for this here. There are two main functions that must be defined, the setup and run functions. You can see the default implementation of the SimulationEngine here.

setup

The setup function typically is divided into two parts. The first is setting the routing policies. This function defines the routing policies that are set for each AS. The second is seeding the announcements. This initializes the announcements at each AS.

set_as_classes

The default implementation of this function can be seen here.

This function takes as input a BasePolicyCls (of type Policy) and a frozen dictionary (non_default_asn_cls_dict) where the ASNs are keys and the values are of type Policy.

Then, the function just iterates through the AS graph, and for each ASN, sets the AS's routing policy to the policy defined in the non_default_asn_cls_dict, or, if none exists, sets it to the BasePolicyCls.

seed_announcements

The default implementation of this function can be seen here.

This function takes as input a list of announcements. Each announcement uses it's seed_asn attribute to find the corresponding AS in the AS graph, and adds the announcement to the localRIB. This is later used in propagation.

run

The run functions default implementation can be seen here.

This function propagate BGP announcements across the entire AS topology, abstracting away packet level and intra-domain routing details. The reason that we abstract away this low level data is because:

• We don’t have good ground truth data for things like iBGP, MED, etc
• We want to run efficiently on normal hardware and still be able to write in a high level language such as Python
• Prior works have done this as well
• The higher level details are what interest us

When propagating announcements, we do the following steps:

• First announcements are propagated from customers to providers
• Then from peers to peers
• Then from providers to customers.

This allows us to converge in O(E) time in a single round of propagation, allowing us to remain efficient enough to both write this all in a high level language such as Python and be efficient enough to run on a basic laptop.

Of course, as discussed in the BGPPolicy section, you can propagate for multiple rounds, this is simply a parameter to the simulator class, and indeed some of our projects use this feature to do things like propagate route leaks (which require two rounds of propagation since they violate the valley free routing rules and principles).

After propagation, the SimulationEngine contains the ASGraph. The ASGraph contains the ASes, and the ASes contain the routing policy which has the localRIB at each AS. In other words, we have the best announcemetns for each prefix at each AS. This can be further utilized for analysis that can determine which ASes where hijacked during an attack, which ASes were disconnected, or which ASes were successfully connected to the legitimate origin (aka victim).

Next: Scenario