aslevel_configuration
commnet-23 branch back into the main branch. While we are doing this, we are also updating the wiki to ensure that all information is consistent. Unfortunately, git wikis are separate from branches, so while these efforts are ongoing, there may be a disconnect between wiki and code. If you need to set up the mini internet right now, please contact us so we can help you use the latest code. In a few days, everything will be in sync again.
The last configuration file describes the AS-level topology and contains additional parameters such as which IP prefix to use for a given inter-AS link.
The file aslevel_links.txt is used to build the mini-Internet whereas the file aslevel_links_students.txt
is part of the mini-Internet website and contains useful information for the students, such as
with which ASes their own AS is directly connected and which IP prefix to use for inter-AS links.
These configuration files can be quite long (one line for every inter-AS link) and thus hard to write manually. We thus provide a script called generate_connections.py that automatically generates these two configuration files. You can run the script with the following command:
python3 generate_connections.py
Once generated by our script, just copy the resulting config files (AS_config.txt, aslevel_links.txt, aslevel_links_students.txt, and hijacks.txt) into the config directory.
The pattern of the AS-level topology is hard coded in the script (regions with two rows of ASes, interconnected by tier 1 ASes and IXPs), but you can easily change the number of regions and size of each region. By default, we create the 12 AS topology shown below, where the four transit ASes (3, 4, 13, 14) are meant to be configured by students while the tier 1 and stub ASes are pre-configured. It's a rather small topology, ideal for testing.
If you want to use your own AS-level topology with a different structure, you must create the corresponding config files manually or by using a custom script.
We now show and explain the content of this configuration file for a 12-ASes topology, generated using our generate_connections.py script. Each line corresponds to an inter-AS link.
C1 C2 C3 C4 C5 C6 C7 C8 C9
----------------------------------------------------------------------------------------------
1 ZURI Provider 3 MUNI Customer 100000 2.5ms 179.1.3.0/24
1 ZURI Provider 4 MUNI Customer 100000 2.5ms 179.1.4.0/24
1 ZURI Peer 2 ZURI Peer 100000 2.5ms 179.1.2.0/24
1 ZURI Peer 80 None Peer 100000 2.5ms 1,2,11,12
1 BASE Peer 81 None Peer 100000 2.5ms 12,14,16
2 ZURI Provider 3 BASE Customer 100000 2.5ms 179.2.3.0/24
2 ZURI Provider 4 BASE Customer 100000 2.5ms 179.2.4.0/24
2 ZURI Peer 11 ZURI Peer 100000 2.5ms 179.2.11.0/24
2 ZURI Peer 80 None Peer 100000 2.5ms 1,2,11,12
2 BASE Peer 82 None Peer 100000 2.5ms 11,13,15
3 LYON Provider 5 ZURI Customer 100000 2.5ms 179.3.5.0/24
3 MILA Provider 6 ZURI Customer 100000 2.5ms 179.3.6.0/24
3 LUGA Peer 4 LUGA Peer 100000 2.5ms 179.3.4.0/24
3 VIEN Peer 81 None Peer 100000 2.5ms 12,14,16
4 LYON Provider 5 ZURI Customer 100000 2.5ms 179.4.5.0/24
4 MILA Provider 6 ZURI Customer 100000 2.5ms 179.4.6.0/24
4 VIEN Peer 82 None Peer 100000 2.5ms 11,13,15
5 ZURI Peer 6 ZURI Peer 100000 2.5ms 179.5.6.0/24
5 BASE Peer 81 None Peer 100000 2.5ms 12,14,16
6 BASE Peer 82 None Peer 100000 2.5ms 11,13,15
11 ZURI Provider 13 MUNI Customer 100000 2.5ms 179.11.13.0/24
11 ZURI Provider 14 MUNI Customer 100000 2.5ms 179.11.14.0/24
11 ZURI Peer 12 ZURI Peer 100000 2.5ms 179.11.12.0/24
11 ZURI Peer 80 None Peer 100000 2.5ms 1,2,11,12
11 BASE Peer 82 None Peer 100000 2.5ms 2,4,6
12 ZURI Provider 13 BASE Customer 100000 2.5ms 179.12.13.0/24
12 ZURI Provider 14 BASE Customer 100000 2.5ms 179.12.14.0/24
12 ZURI Peer 1 ZURI Peer 100000 2.5ms 179.1.12.0/24
12 ZURI Peer 80 None Peer 100000 2.5ms 1,2,11,12
12 BASE Peer 81 None Peer 100000 2.5ms 1,3,5
13 LYON Provider 15 ZURI Customer 100000 2.5ms 179.13.15.0/24
13 MILA Provider 16 ZURI Customer 100000 2.5ms 179.13.16.0/24
13 LUGA Peer 14 LUGA Peer 100000 2.5ms 179.13.14.0/24
13 VIEN Peer 82 None Peer 100000 2.5ms 2,4,6
14 LYON Provider 15 ZURI Customer 100000 2.5ms 179.14.15.0/24
14 MILA Provider 16 ZURI Customer 100000 2.5ms 179.14.16.0/24
14 VIEN Peer 81 None Peer 100000 2.5ms 1,3,5
15 ZURI Peer 16 ZURI Peer 100000 2.5ms 179.15.16.0/24
15 BASE Peer 82 None Peer 100000 2.5ms 2,4,6
16 BASE Peer 81 None Peer 100000 2.5ms 1,3,5
Below is the description of each column:
- C1: AS number of the AS at one end of the link.
- C2: Router within the AS in C1 that is connected to the other AS.
- C3: With which type of business relationship the AS in C1 is connected to the neighboring AS in C4. For instance, the second line indicates that AS1 is a provider of AS4, and AS4 a customer of AS1.
- C4: Same as C1 but for the other end of the link.
- C5: Same as C2 but for the other end of the link.
- C6: Same as C3 but for the other end of the link.
- C7: The throughput of the link.
- C8: The delay of the link.
-
C9: Two possible cases:
- When its an AS-to-AS link: IP prefix to use for the eBGP sessions.
- When its an AS-to-IXP link: to which other ASes the IXP is allowed to advertise the prefix.
To illustrate, the second line indicates that ZURI in AS1 is connected to MUNI in AS3, and AS1 is the provider of AS3.
To reduce the server load, an IXP AS contains only one router. Therefore, C5 is None when there is an IXP.
C9 is used to autoconfigure the different networks and achieve network-wide connectivity when using the Config flag in the AS_config.txt configuration file. For example, if AS 1 uses "1,2,11,12", the IXP would forward the advertisement to ASes 1, 2, 11, and 12. You can be fairly liberal in setting these values: if the IXP is not connected to one of the ASes, it is simply ignored; e.g. using "1,2,11,12,999" would have the same effect.
You only need to be careful not to advertise your prefix to direct or indirect customers via the IXP, as this would invalidate business relations.
For example, AS 1 should not advertise to ASes 3 or 5 via IXP 81. By default, the stub (or buffer, see below) ASes do not follow this rule and advertise to their own region to give students some advertisements they can deny. This makes debugging their filters easier. You can disable this in the script.
When creating these config files yourself, you should only have a single line in the config file for each link, not one line per endpoint.
We show and explain the content of the aslevel_links_students.txt configuration file for a 12-ASes topology and when generated using the generate_connections.py script.
Below is a snippet of this configuration file.
C1 C2 C3 C4 C5 C6 C7
------------------------------------------------------------------------------
1 ZURI Provider 3 MUNI Customer 179.1.3.1/24
3 MUNI Customer 1 ZURI Provider 179.1.3.3/24
1 ZURI Provider 4 MUNI Customer 179.1.4.1/24
4 MUNI Customer 1 ZURI Provider 179.1.4.4/24
1 ZURI Peer 2 ZURI Peer 179.1.2.1/24
2 ZURI Peer 1 ZURI Peer 179.1.2.2/24
1 ZURI Peer 80 None Peer 180.80.0.1/24
80 None Peer 1 ZURI Peer 180.80.0.80/24
Below is the description of each column:
- C1: AS number of the AS at one end of the link.
- C2: Router within the AS in C1 that is connected to the other AS.
- C3: With which type of business relationship the AS in C1 is connected to the neighboring AS in C4. For instance, the first line indicates that AS1 is a provider of AS3.
- C4: Same as C1 but for the other end of the link.
- C5: Same as C2 but for the other end of the link.
- C6: Same as C3 but for the other end of the link.
- C7: IP address which is shown on the mini-Internet website to tell students which IP address they should use for their eBGP connections.
The content of this file is used to generate the "AS connections" file on the mini-Internet website. Student can use this file to figure out which IPs/prefixes they should use for their eBGP sessions towards their neighbors.
By default, IPs are pre-selected for student ASes connected to pre-configured TA ASes.
For links between student ASes, only a subnet is shown, such that students may negotiate the details of their connection between each other.
If you also want concrete IP addresses assigned between student ASes, you can set the respective parameter in the generate_connections.py script.
You can modify the content of this file at runtime: the website will automatically show the newest version.
When creating this file manually, you need one line per endpoint, including the IP address on this side of the link.
To allow better testing of RPKI, the stub ASes can try to permanently hijack each others prefix (only for ASes in the same region). This is experimental and disabled by default, but you can enable it in the script. If you enable this, two additional auto-configured ASes are added to each region to act as a buffer between the malicious stubs and student ASes, such that all students can set up connections to their customers in the same way, and do not have to consider malicious customers. Also, if the stubs are malicious, the buffer ASes will take the role of advertising "too much" via the IXP.
We recommend doing some preliminary testing if you use this (experimental) feature. In particular, the MATRIX and MEASUREMENT services in the stub topo need to be carefully placed such that the pings and traceroutes do not end in black holes. The border routers that propagate the hijacks have default rules for the hijacked prefix -- if e.g. the matrix pings go over the border routers, the response will be blackholed.