aslevel_configuration - nsg-ethz/mini_internet_project GitHub Wiki

:warning: We are currently merging updates from this year's iteration of our lecture from the 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.

AS-level configuration

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.

Automatic generation of the configuration files

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.

:warning: The script requires the names of routers, and which routers are connected to which provider/customer/peer/ixp. Thus, if you changed the layer-3 topology, you must update the script accordingly. All changeable parameters are clearly indicated at the top of the script.

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.

`aslevel_links.txt`

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.

`aslevel_links_students.txt`

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.

Permanent hijacks between stubs

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.