Part 3 - Intra-Domain Routing (27.05. - 31.05.2024)
This week’s tasks are even longer, and descriptions to help you are less detailed than last week’s. Also, not all information given is relevant to the specific tasks. This is intentional. Remember the problem-solving skills you acquired last week and that you can use a search engine of your preference to acquire additional knowledge. Make a plan before you configure anything! And don’t forget regular backups.
Topology reminder
Task 1 (Question 1.2)
Configure IP addresses and enable OSPF network-wide by establishing OSPF adjacencies between neighboring routers. Then, make sure to advertise all your IPv4 subnets (including the one in L2S) in OSPF to enable end-to-end connectivity between all hosts in your AS.
You will not have connectivity with the hosts in L2N as they have no IP addresses yet.
Configure IP addresses
Before configuring OSPF, you must configure all IP addresses on each interface of your routers and their directly connected host.
Unlike for the task last week, you must use the IP addresses shown in the L3 topology.
For example, for the router interfaces between CAIR and KHAR, you have to use the subnet X.0.1.0/24.
The interface in CAIR that is connected to KHAR must have the IP address X.0.1.1, and the interface in KHAR that is connected to CAIR must have the IP address X.0.1.2 (where X is your group number).
This task is somewhat repetitive, and you can nicely split it among team members.
You can also use scripts and/or compose the configurations in a text editor to paste them later at once.
Every router also has a loopback interface named lo that you have to configure.
The router with ID Y has the loopback address X.[150+Y].0.1/24 where X is your group number.
Router IDs are shown in the topology map on the symbol for each router, e.g., the ID of CAIR is 1.
As an example, the loopback address of the router CAIR for group 10 is 10.151.0.1/24.
For the connection between the routers and their corresponding host, you have to use the subnet X.[100+Y].0.0/24, where X is your group number, and Y is the ID of the router.
The host gets the IP address X.[100+Y].0.1, and the interface of the router that is connected to this host gets the IP address X.[100+Y].0.2.
For example, the subnet used for group 85 between the ACCR router and the corresponding host is 85.108.0.0/24.
The interface at the router ACCR that is connected to the host is called host and uses 85.108.0.2/24.
The interface of the host connected to the router is called ACCRrouter and uses the IP address 85.108.0.1/24.
Warning
Do not reconfigure the dns interface on KINS, the measurement interface on NAIR, and the matrix interface on LUAN, as the connected services will become unreachable if you change the IP addresses.
Configure OSPF
Be sure that each host can ping its directly connected router. Then, you can start configuring OSPF.
Enable OSPF on each router, configure the router ID, and activate OSPF on all connected subnets that belong to your prefix. Do not forget to activate OSPF on the subnet of the loopback interface. For routers with special connections like L2 networks and matrix/DNS/measurement services: activate OSPF for these subnets as well!
Later, you will configure
179.0.0.0/24and180.0.0.0/24subnets between you and neighboring ASes. Do not include these subnets in OSPF.
Checking your solution
You can see the current router config with the command
show running-config, which can be abbreviated tosh run. You can also abbreviate other commands!
Verify that each host in your network can reach each other host.
Also, use show ip route ospf to verify that all your routers can reach all other routers within your network.
The measurement service is a special case: only NAIR can ping it successfully, that is, receive replies from it (see this explanation to learn more).
All interfaces between routers should be visible in OSPF, as well as the router loopback interfaces.
In particular, verify that the subnets of the DNS server and the measurement service are visible in OSPF (for instance, with show ip route ospf).
We give more detail about the DNS server and the measurement service in the tools section.
From now on, always prefer to launch a traceroute from hosts or the measurement service because they can use the DNS service, while routers cannot.
If one host cannot access the DNS server because the OSPF configuration is not ready yet, run traceroute with the option -n so that it does not try to translate each IP address found on the path.
Hint:
Consider that each traceroute hop is detected with a new packet, independent from the previous packet.
Thus, on a traceroute from CAIR to CAPE, you may see ACCR as hop 2 and NAIR as hop 3, even though the path CAIR-ACCR-NAIR does not exist.
This means that the first packet took the path CAIR-ACCR, and the second packet the path CAIR-KHAR-NAIR.
Task 2 (Question 1.3; optional)
Configure load-balancing
In this question, you will configure OSPF to load-balance traffic between L2N and L2S on specific paths; or more precisely, between CAPE and ACCR where the L2 networks are connected.
If you use equal weights for every link, you can observe that traffic between these routers currently has one shortest path: CAPE-LUAN-ACCR.
By choosing suitable OSPF weights, you can control which paths traffic takes, including on which paths traffic is load-balanced, independently of the number of hops.
Concretely, configure the OSPF weights such that the traffic between CAPE and ACCR is load-balanced on the following two paths (and only those two, and no other path): CAPE-LUAN-ACCR and CAPE-NAIR-KINS-ACCR (for both directions).
Checking your solution
As in the previous question, verify your solution using traceroute.
Make sure to verify that the path CAPE-LUAN-KINS-ACCR is not taken.
Task 3 (Question 2.1)
Configure iBGP
Configure internal BGP sessions (iBGP) between all pairs of routers (full-mesh).
When you establish a BGP session, you must use the loopback address for each endpoint of the connection.
The loopback address is a virtual address that is always up as long as the router runs.
Using the loopback interface instead of any other physical interface prevents the BGP session from going down if a physical interface becomes unavailable.
To use loopback addresses for your BGP sessions, you will have to use the update-source command when you configure the internal BGP sessions.
It is also a good idea to configure next-hop-self for iBGP sessions now.
This will only become important once you establish eBGP sessions next week, but it does not hurt to configure it already. Take a peek at how to configure next-hop-self.
Checking your solution
Verify that each of your routers has an iBGP session with all the other routers using the command show ip bgp summary. You will see a list of all BGP neighbors.
If there is a time entry in the column Up/Down, then the session has successfully been established. On each of your routers, you should see an established session with each of your other routers.
Make sure that no sessions are missing or down, or you may encounter problems later on.
Tutorials
See the instructions below to sove this week's tasks.
Configure static routes
OSPF and BGP are dynamic routing protocols that automatically route around network failures. In some cases, though, defining routes statically is useful. Static routes are set once and for all, independently of the network conditions. Static routes are simply configured by specifying the IP prefix along with the IP next-hop or interface. As an illustration:
router# conf t
router(config)# ip route 3.0.0.0/24 2.0.0.2
router(config)# ip route 4.0.0.0/24 someinterface
would force the router to direct all traffic destined to 3.0.0.0/24 to 2.0.0.2
and all traffic to 4.0.0.0/24 to leave via the interface someinterface.
You can verify that a static route has been installed correctly using
show ip route static:
Configure OSPF
OSPF routers flood IP routes over OSPF adjacencies.
FRR routers continuously (and automatically) probe any OSPF-enabled interface to discover new neighbors to establish adjacencies.
By default, FRR activates OSPF on any interface whose prefix is covered by a network command under the
router ospf part of the configuration.
FRR automatically attempts to establish OSPF sessions on any interface where OSPF is active.
A session is established if the routers on both ends of the link have enabled OSPF.
For example, the following commands configure OSPF for CAIR in group 3.
First, they set OSPF router-id (using the loopback address).
Next, they activate OSPF on any interface whose IP address falls under 3.151.0.0/24 or 3.0.1.0/24
router# conf t
router(config)# router ospf
router(config-router)# ospf router-id 3.151.0.1
router(config-router)# network 3.151.0.0/24 area 0
router(config-router)# network 3.0.1.0/24 area 0
router(config-router)# exit
router(config)# exit
This is not the complete configuration for
CAIR. Be sure to include all connected (internal) subnets. Do not include the subnets between you and your eBGP peers.
OSPF has scalability issues when there is a large number of routers. To make it more scalable, the router topology can be hierarchically divided into what is called “areas”. In this assignment, your network is small, and you do not need more than one area: you will only use area 0.
To check the OSPF neighbors of a router, you can use the following command:
router# show ip ospf neighbor
Neighbor ID Pri State Up Time Dead Time Address Interface RXmtL RqstL DBsmL
3.152.0.1 1 Full/DR 21h25m03s 37.053s 3.0.1.2 port_KHAR:3.0.1.1 0 0 0
3.157.0.1 1 Full/Backup 21h24m39s 34.036s 3.0.2.2 port_KINS:3.0.2.1 0 0 0
3.158.0.1 1 Full/Backup 21h24m39s 38.484s 3.0.3.2 port_ACCR:3.0.3.1 0 0 0
The
Neighbormay be a different IP than you expect since it is an ID that may come from any interface, e.g. also thesshinterface. Do not worry about this.
Here, we see that the router has established two OSPF sessions with two neighbors, 3.0.1.2 and 3.0.2.2.
Routers within the same area exchange information about all their sessions with each other, such that every router has complete knowledge of the network topology.
Using this information, they exchange messages containing their distances to each other.
Let’s look at the routes received by OSPF with the following command.
router# show ip route ospf
O 3.0.1.0/24 [110/1] is directly connected, port_KHAR, weight 1, 21:28:48
O 3.0.2.0/24 [110/1] is directly connected, port_KINS, weight 1, 21:29:44
O 3.0.3.0/24 [110/1] is directly connected, port_ACCR, weight 1, 21:29:44
O>* 3.0.4.0/24 [110/2] via 3.0.1.2, port_KHAR, weight 1, 21:28:38
(...)
You can see that our router has learned how to reach the subnet 3.0.4.0/24 via a neighbor.
The O at the beginning of each line indicates that the router has learned this subnet from OSPF.
To reach it, it must send the packets to its neighbor router 3.0.1.2.
If you want to have more information about the routers of this OSPF area, you can use show ip ospf database.
With OSPF, each link between two routers has a specific weight; and only the
shortest paths are used to forward packets. Below is an example of how you set
the weight of a link connected to interface INTERFACENAME to 900:
show ip ospf interface <interface>.
Use these commands to configure the OSPF weights in your own network.
Note that the weights are not bidirectional, i.e. if you want the link between ACCR and LUAN to have weight 20, you need to configure the corresponding interface on both routers!
You can check the current total weight of learned routes with the show ip route ospf command:
router# show ip route ospf
O 3.0.1.0/24 [110/1] is directly connected, port_KHAR, weight 1, 21:28:48
O 3.0.2.0/24 [110/1] is directly connected, port_KINS, weight 1, 21:29:44
O 3.0.3.0/24 [110/1] is directly connected, port_ACCR, weight 1, 21:29:44
O>* 3.0.4.0/24 [110/2] via 3.0.1.2, port_KHAR, weight 1, 21:28:38
(...)
The mentioned
weight 1in the output is not the total cost of the route, and does not correspond to any OSPF weight you configured; it is a different parameter that you can ignore.
Configure BGP
While OSPF is used to provide IP connectivity within an AS, BGP is used to advertise prefixes between different ASes. Unlike OSPF, BGP routers will not automatically establish sessions.
Each session needs to be configured individually.
The following commands show you how to: start a BGP process and establish two BGP sessions with neighboring routers.
The integer following router bgp indicates your AS number.
Here, the local AS number is 2:
router# conf t
router(config)# router bgp 2
router(config-router)# neighbor 179.2.15.123 remote-as 15
router(config-router)# neighbor 2.151.0.1 remote-as 2
By default, whenever the remote-as is different from the local number (here 2), the BGP session is configured as an external one (i.e., an eBGP session is established).
In contrast, when the remote-as is equivalent to the local one, the BGP session is configured as an internal one (iBGP). Here, the first session is an eBGP session, established with a router in another AS 179.2.15.123, while the second one is an internal session, established with a router within your AS 2.151.0.1.
For now, you should see that our two BGP sessions are up and allow advertising/receiving prefixes.
You can check the state of your BGP sessions
using the command show ip bgp summary:
router# show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.151.0.1 4 2 3 6 0 0 0 00:01:16 0
179.2.15.123 4 15 2009 1979 0 0 0 01:31:42 1
To advertise your /8 prefix on a BGP session,
you can just use the following command:
As soon as you do that, your neighbor 179.2.15.123 receives this advertisement and knows that it can forward to you all the packets with a destination IP in the subnet 2.0.0.0/8.
Note that when you advertise a prefix, it generally means you know how to reach this prefix. Otherwise, you will drop the packets, and your neighbor will not be very happy.
BGP update-source for iBGP sessions
By default, when a router establishes an iBGP session with a peer, it uses the IP address of the interface closest to the iBGP peer as the source address.
This is fine as long as this interface is up.
If this interface goes down but the actual router is still running, the iBGP connection will tear down even though the router may be reachable over a different path/interface.
In practice, operators therefore often use so-called “loopback” interfaces as the source of the iBGP connections.
Loopback interfaces are virtual interfaces with an IP address that uniquely identifies the router in your network.
For example, if you are group 7 and you want to configure an iBGP session from CAIR to KHAR, you could use the following commands on CAIR:
router# conf t
router(config)# router bgp 7
router(config-router)# neighbor 7.152.0.1 remote-as 7
router(config-router)# neighbor 7.152.0.1 update-source lo
7.152.0.1 is the loopback interface IP of KHAR.
With update-source lo, you make sure that the CAIR router is using its own loopback interface address as the source address.
Tools to help you
As any network operator, you must verify that your configuration does what you want, and debug it in case something goes wrong. We offer you several tools that you can use to verify your configuration. These tools are either incorporated in the Mini-Internet or are made available on the Mini-Internet website. These tools are similar to the ones network operators use in practice.
Mini-Internet Website
Aside from this site, there is a Mini-Internet website available at internet.netd.cs.tu-dresden.de that provides the following information and tools:
- connectivity matrix A matrix that will tell you what other ASes you can reach and whether the paths violate the expected business relationships. Before you set up eBGP sessions, everything will be red. As soon as you set up the eBGP sessions with your neighbors, the matrix will turn green or orange (if the inter-AS path is yet invalid). At the end of this assignment, we hope to see this matrix completely green! The matrix is updated every few minutes.
- AS connections A list of the interconnections between the different ASes.
- BGP looking glass
A service that shows you the routing tables of nearly every router in the Mini-Internet.
In practice, looking glasses are servers that display the routing information of an IP router.
For example, SWITCH, the Swiss educational network, gives public access to its looking glass.
This is useful to see how your BGP advertisements look from a remote point of view.
On our Mini-Internet website (under the
looking glasstab), we provide such a looking glass service for the Mini-Internet. Simply indicate a group number and a router name and the website will print the result of ashow ip bgpexecuted on that router. The looking-glass output is updated every few minutes and the top line of the output shows the time of the last update. - BGP policy analyzer
To help you debug your BGP policy configurations, the looking-glass page also shows the output of our BGP policy analyzer.
This analyzer automatically parses the looking-glass files and infers the currently configured BGP policies by looking at which prefixes each AS advertises to its neighboring ASes.
The tool detects Route Leaks, which are, in a nutshell, violations of the expected policies following the business agreements.
This information will help you to see if your configured policies are correct, and if not, will help you to debug.
The analyzer does not detect all possible misconfigurations. It can help you debug, but you must still check your configuration manually.
No detected violations are not a guarantee that your BGP configuration is correct.
Built-in tools
Measurement container
We have set up a measurement service that will enable you to launch traceroute from any AS (and not necessarily only your own AS), towards any destination in the Mini-Internet.
This will help you to analyze the paths used toward your network.
Note
For the measurement service to fully function, you must complete its configuration.
In short, use the service like this, for more details see below:
The measurement service is connected to each AS via the interface measurement_X of the router NAIR.
The IP address of this interface is pre-configured and follows the convention X.0.199.1/24, and the measurement service has the IP address X.0.199.2/24, where X is your group number.
For example, if you are group 63, your pre-configured IP address on the interface measurement_63 at CAIR will be 63.0.199.1/24, and you can reach the measurement service at 63.0.199.2/24.
The X.0.199.0/24 subnet must be reachable from anywhere in your network, or the measurement service will not work.
You must therefore add this subnet to your OSPF configuration.
The measurement service itself is connected to each AS via one of its dedicated interfaces named groupX in the measurement service.
Sending traffic via this interface will force it to go through the connected AS.
For example, consider the following two (equivalent) commands:
The -i' flag specifies the interface to use, in this case, the interface connected to AS 11.
This means thattraceroutewill send all traffic towardNAIRin AS 11 as the first hop.
Consequently, AS 11 will have to deal with routing the packets toward the destination and you'll be able to observe the path towardCAIR` in AS 1 starting from AS 11.
DNS is configured by default on the measurement service, so you can use both hostnames or ip addresses.
To reach a router, use <router-name>.groupX (e.g. cair.group1), and to reach a host, use the hostname host.<router-name>.groupX (e.g. host.cair.group1).
The interfaces between ASes (starting with 179.) or between ASes and IXPS (starting with 180.) do not have DNS entries.
Have a look at the IP addresses and network topology to figure out where the traffic ended up!
Note
Recall that TA-managed ASes use a different internal topology, so the IP addresses may not match with the ones in your own AS. For interpretable results, launch measurements between student-managed ASes only.
The measurement service can launch traceroutes from any AS towards any device; but it does not know (and propagate) routes starting from itself towards the rest of the mini-Internet.
Otherwise, ASes would use the measurement service to reach each other (defeating the purpose of the mini-Internet, and, probably also crashing the measurement service).
There is only one exception: The measurement service knows a route (starting from itself) towards the directly connected router NAIR.
This means that only NAIR can successfully ping the measurement service.
The measurement service is public and shared among all groups. Do not create, modify, or delete any files on the measurement service. Use it only for launching traceroutes!
In practice, network operators use large-scale Internet measurement platforms such as RIPE Atlas to assess the connectivity of their network from outside.
DNS service
To help you decode your traceroute output, we have set up a DNS server and have pre-configured your hosts to use it.
Note
For the DNS service to fully function, you have to complete its configuration.
If the DNS server is used, the IP addresses in the traceroute output will be replaced by the corresponding router names.
For example, 12.0.2.2 will be translated into kins.group12, because this is the IP address configured on the router KINS of group 12.
The DNS server is located in a container connected to the interface dns of the router KINS.
The IP address on that interface is pre-configured, and you must not change it.
Also, each host is pre-configured to use the DNS server.
However, only hosts can use the DNS server, while routers do not.
Of course, hosts can only use the DNS server if they can reach the network 198.0.0.0/24 (where the DNS server is located).
You must add this subnet to your OSPF configuration.
Additional Resources
Reinforce your understanding of how OSPF and iBGP work together by watching the following video:
Hopefully, after completing this week’s tasks, you have noticed that iBGP peering does not scale well. To find out about the smarter solution that is used in real life, read the following article.
If you are interested in some much more detailed information on OSPF you can check out this website.
page version 1.0.2 - last edited June 2nd, 2024