Commit ef5b55e0 authored by Thomas Holterbach's avatar Thomas Holterbach
Browse files

Added Task 2 and 3 for the BGP MPLS VPN exercise

parent 426b410c
......@@ -356,9 +356,297 @@ It works too! And you can see that the first hop is hidden, as the packet is in
## Task 2: Configure the VPN over BGP using VRF
We'll introduce this task soon!
Now that the BGP free core is configured and that the Swisscom network can forward traffic between its neighbors, it is time to configure the VPNs such that Credit Suisse and UBS can _only_ talk to each other. Note that Swisscom has two types of connection to neighboring sites: the central branch of Credit Suisse is connected to Swisscom via BGP whereas the other branches are directly connected via a L2 switch (both of these connections do occur in practice).
For this, we will use VRF.
In order to use VRF, the router interfaces (in AS 1) connected to a bank site need to be assigned to particular VRF.
FRRouting builds on Linux VRF, and the VRF interfaces need to be created in Linux before we can configure them in FRRouting. For your convenience, this is automatically done in the default configuration when building the mini-Internet,
so you do not have to worry about configuring them correctly.
You can see a list of the interfaces in the `default` VRF with the command `show interface brief`.
To show interfaces in another VRFs, you need to use the command `show interface vrf VRF_NAME brief`, where you can either enter a specific VRF, or use `all`.
For example, this is the output for `show interface vrf all brief` on `R1`:
```
R1_router# show interface vrf all brief
Interface Status VRF Addresses
--------- ------ --- ---------
VRF_CS up VRF_CS
ext_20_CENT1 up VRF_CS 179.0.0.2/24
Interface Status VRF Addresses
--------- ------ --- ---------
R1-L2 up VRF_UBS 10.0.0.2/16
VRF_UBS up VRF_UBS
Interface Status VRF Addresses
--------- ------ --- ---------
lo up default 1.151.0.1/32
port_R2 up default 1.0.0.1/24
port_R3 up default 1.0.1.1/24
port_R5 up default 1.0.2.1/24
ssh up default 158.1.10.1/16
```
As you can see, we will use two VRFs in this exercise: `VRF_CS` for Credit Suisse and `VRF_UBS` for UBS.
Let's have a closer look at `VRF_CS` using `show interface vrf VRF_CS`:
```
R1_router# show interface vrf VRF_CS brief
Interface Status VRF Addresses
--------- ------ --- ---------
VRF_CS up VRF_CS
ext_20_CENT1 up VRF_CS 179.0.0.2/24
```
The first entry is the virtual interface used by the VRF, you do not have to use it. The second interface is the interface of the router connected to the router `CENT1` in AS20.
:information-source: You might notice that you cannot ping `CENT1` (`179.0.0.1`) from `R1`, as this address is not known outside the VRF. Unfortunately, it is currently impossible to specify the VRF interface as a ping source with the `ping` command in `vtysh`, but it is possible with the Linux `ping`, e.g. using `./access.sh R1 ping -I ext_20_CENT1 179.0.0.1`.
### Configuring eBGP in a VRF
Your first step is to configure eBGP between Swisscom and the central branch of Credit Suisse (AS20).
Importantly, you have to run the BGP session in the VRF `VRF_CS`.
To do that, use the command `router bgp 1 vrf VRF_CS` when to configure this BGP session on `R1`.
You can find more information on how to configure BGP in a VRF in [the FRR docs](http://docs.frrouting.org/en/latest/bgp.html).
Do not forget that you also need to configure the session in the router `CENT1`.
You do not need to specify a `VRF` in `CENT1`. Can you explain why?
In AS20, i.e. router `CENT1`, you should not only advertise the public prefix of Credit Suisse (`20.0.0.0/8`), but _also_ the internal prefixes (`192.168.0.1/24` and `10.1.0.0/24`). Using VRF, Swisscom can ensure that the internal prefixes of Credit Suisse are only advertised to other sites of Credit Suisse. We will get to that later.
When you have configured the eBGP session between Swisscom and AS20, Swisscom will learn prefixes from AS20.
However, these prefixes will be in the VRF routing table for `VRF_CS`, and not in the `default` routing table. Thus, the prefix of AS20 (`20.0.0.0/8`) will not be reachable from the default VRF in the Swisscom network. You can verify this with `sh ip bgp summary` and `sh ip bgp` on R1:
```
R1_router# sh ip bgp summary
IPv4 Unicast Summary:
BGP router identifier 1.151.0.1, local AS number 1 vrf-id 0
BGP table version 8
RIB entries 3, using 552 bytes of memory
Peers 3, using 61 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
1.152.0.1 4 1 22 34 0 0 0 00:08:09 1
1.153.0.1 4 1 28 47 0 0 0 00:08:09 1
1.154.0.1 4 1 30 42 0 0 0 00:08:10 2
```
```
R1_router# sh ip bgp
BGP table version is 8, local router ID is 1.151.0.1, vrf id 0
Default local pref 100, local AS 1
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0/8 1.152.0.1 0 100 0 i
* i 1.153.0.1 0 100 0 i
* i 1.154.0.1 0 100 0 i
*> 0.0.0.0 0 32768 i
*>i30.0.0.0/8 1.154.0.1 0 100 0 30 i
```
As you can see, neither the peer `179.0.0.1` nor the prefix `20.0.0.0/8` appear in this list. BGP sessions in different VRFs (here `default` and `VRF_CS`), and all advertised/received prefixes, are completely separated.
To see the BGP information for `VRF_CS`, you can use `sh ip bgp summary vrf VRF_CS` and `sh ip bgp vrf VRF_CS`:
```
R1_router# sh ip bgp vrf VRF_CS summary
IPv4 Unicast Summary:
BGP router identifier 179.0.0.2, local AS number 1 vrf-id 2
BGP table version 12
RIB entries 11, using 2024 bytes of memory
Peers 1, using 20 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
179.0.0.1 4 20 27 26 0 0 0 00:12:36 3
Total number of neighbors 1
```
```
R1_router# sh ip bgp vrf VRF_CS
BGP table version is 14, local router ID is 179.0.0.2, vrf id 2
Default local pref 100, local AS 1
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/8 0.0.0.0 0 32768 i
*> 10.1.0.0/24 179.0.0.1 0 0 20 i
*> 20.0.0.0/8 179.0.0.1 0 0 20 i
*> 192.168.0.0/24 179.0.0.1 0 0 20 i
Displayed 4 routes and 4 total paths
```
You can see that the eBGP session with AS20 is established in the vrf `VRF_CS`, and that `R1` receives the three prefixes advertised by AS20.
### Configure the VPNs
To maintain separation between traffic from the different banks, we will now configure BGP VPNs over MPLS.
1. We need to enable the BGP VPN sessions between the different routers using the `vpn` [address-family](http://docs.frrouting.org/en/latest/bgp.html#address-families). Here is an example for the router `R1`, which has a BGP VPN connection with `R2`, `R3` and `R4`.
```
address-family ipv4 vpn
neighbor 1.152.0.1 activate
neighbor 1.153.0.1 activate
neighbor 1.154.0.1 activate
```
2. You need to enable BGP to advertise the prefixes over the VPN using MPLS. You can do that using the command [`label vpn export auto`](http://docs.frrouting.org/en/latest/bgp.html#clicmd-labelvpnexport(0..1048575)|auto).
3. You must enable the [import and export](http://docs.frrouting.org/en/latest/bgp.html#clicmd-import|exportvpn) of the routes between the VRF and the VPN.
4. You need to configure a _route distinguisher_ as well as a _route target_. For now, always use the same route target for import _and_ export for each VRF, so that the prefixes in one site are advertised to all the other sites of the same bank.
Now, we can run the command `sh ip bgp vrf VRF_CS` in the router `R3` to verify that the routes are correctly announced between the `VRF_CS` in `R3` and the `VRF_CS` in routers `R1` and `R2`.
```
R3_router# sh ip bgp vrf VRF_CS
BGP table version is 11, local router ID is 10.1.1.2, vrf id 2
Default local pref 100, local AS 1
Network Next Hop Metric LocPrf Weight Path
*> 10.1.0.0/24 1.151.0.1@0< 0 100 0 20 i
*> 10.1.1.0/24 0.0.0.0 0 32768 ?
*> 20.0.0.0/8 1.151.0.1@0< 0 100 0 20 i
*> 192.168.0.0/24 1.151.0.1@0< 0 100 0 20 i
*> 192.168.1.0/24 1.152.0.1@0< 0 100 0 ?
Displayed 5 routes and 5 total paths
```
And we can also run the command `show mpls table` to verify that the traffic between the different sites are indeed separated using MPLS labels.
Below is the output of that command in the router `R3`.
```
R3_router# show mpls table
Inbound Label Type Nexthop Outbound Label
----------------------------------------------
16 LDP 1.0.1.1 implicit-null
17 LDP 1.0.1.1 16
18 LDP 1.0.1.1 18
19 LDP 1.0.1.1 19
80 BGP VRF_CS -
4294967295 LDP 1.0.1.1 implicit-null
4294967295 LDP 0.0.0.0 implicit-null
```
We can see that the label 80 is used for the BGP VPN for the `VRF_CS`. If you run a `tcpdump`, you will see that the packets going from the Oerlikon branch of Credit Suisse to the central branch of Credit Suisse are tagged with two MPLS labels within the Swisscom network. One is used for the forwarding within the Swisscom network (BGP free Core), and the other one is used for the BGP VPN.
Finally, you can verify that the connectivity is working fine by running `ping` and `traceroute`. For instance, Here is the output of a traceroute from the Credit Suisse branch at Oerlikon to the Credit Suisse branch at Paradeplatz. Do not forget to use the `-n` option when you run a traceroute from a host, so it does not try to translate IPs into domain names.
```
root@oerl_host:/# traceroute 10.1.1.1 -n
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 10.1.1.1 7.756 ms 7.706 ms 7.676 ms
```
The sites are connected, and hops 1 to 3 are hidden because of the MPLS tunnel in the Swisscom network.
## Task 3: Configure advanced routing policies
We'll introduce this task soon!
### Configure routing policies between the Credit Suisse sites
Until now, all Credit Suisse sites are interconnected.
However, Credit Suisse has asked Swisscom to add the following constraint:
The branches at Oerlikon and Paradeplatz should both be able to communicate with the Central branch (and the Central branch with them), but they should _not_ be able to communicate with each other.
It is your next task to implement this constraint.
You can achieve this by modifying the BGP configuration of some routers in AS1.
Concretely, you will have to use multiple different _route targets_ for each branch, and update your import/export rules accordingly.
When you have updated your configuration, you can verify your solution in multiple ways:
- You could check that the router `R2` does not receive the prefix `10.1.1.0/24` in the VRF `VRF_CS`.
- You could also verify that there is no connectivity with `ping` and `traceroute`.
### Configure routing for external prefixes in the Swisscom network
Besides providing L3VPN, Swisscom is also providing basic L3 connectivity to its customers. For instance, Credit Suisse owns the public prefix `20.0.0.0/8` and would like Swisscom to advertise it to the rest of the mini-Internet. Same for SWITCH, who would like its prefix `30.0.0.0/8` to be reachable by the other ASes in the mini-Internet.
**Goal**: configure the routers in the mini-Internet such that SWITCH and the central branch of Credit Suisse can talk to each other. Here, only the public prefixes (i.e., `20.0.0.0/8` for Credit Suisse and `30.0.0.0/8` for SWITCH) must be advertised in the mini-Intenret.
**Challenge**: the interface in router `R1` connected to the central branch of Credit Suisse (AS20) is in the VRF `VRF_CS`. This leads to two problems:
1. `R1` learns the prefix `20.0.0.0/8` (advertised by AS20) in the vrf `VRF_CS`, and thus that prefix will not be advertised to `R2`, `R3` and `R4` via iBGP.
2. The public prefix learnt by `R1` via iBGP (here only `30.0.0.0/8`) are in the `default` vrf only, and thus not advertised to
the `AS20`.
To solve these two problems, we will leak routes from the vrf `VRF_CS` to the `default` vrf and vice versa.
To do that you can use the capabilities provided by BGP VPN. You can `import` and `export` vpn routes in the bgp instance of the **`default`** vrf (i.e., in `router bgp 1`). More precisely:
- To leak routes from the vrf `VRF_CS` to the `default` vrf, you can `import` routes with a route target equal to `20:1`.
- To leak routes from the `default` vrf to the vrf `VRF_CS`, you can `export` the routes with a route distinguisher and a route target equal to `1:1`. Then, in the bgp instance of the vrf `VRF_CS`, make sure to import the vpn routes with a route target equal to `1:1`.
You can verify that the routes have been leaked by showing the bgp routes in the different vrfs. For instance
in the `default` VRF of `R1` we do see the prefix `20.0.0.0/8`.
```
R1_router# sh ip bgp
BGP table version is 3, local router ID is 1.151.0.1, vrf id 0
Default local pref 100, local AS 1
Network Next Hop Metric LocPrf Weight Path
* i1.0.0.0/8 1.154.0.1 0 100 0 i
* i 1.153.0.1 0 100 0 i
* i 1.152.0.1 0 100 0 i
*> 0.0.0.0 0 32768 i
* 20.0.0.0/8 179.0.0.1@2 0 0 20 i
*> 0.0.0.0 0 32768 i
*>i30.0.0.0/8 1.154.0.1 0 100 0 30 i
```
and in the vrf `VRF_CS` we do see the prefix `30.0.0.0/8`.
```
R1_router# sh ip bgp vrf VRF_CS
BGP table version is 7, local router ID is 179.0.0.2, vrf id 2
Default local pref 100, local AS 1
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0/8 1.154.0.1@0< 0 100 0 i
* 1.153.0.1@0< 0 100 0 i
* 1.152.0.1@0< 0 100 0 i
0.0.0.0@0< 0 32768 i
*> 0.0.0.0 0 32768 i
*> 10.1.0.0/24 179.0.0.1 0 0 20 i
*> 10.1.1.0/24 1.153.0.1@0< 0 100 0 ?
*> 20.0.0.0/8 179.0.0.1 0 0 20 i
0.0.0.0@0< 0 32768 i
*> 30.0.0.0/8 1.154.0.1@0< 0 100 0 30 i
*> 192.168.0.0/24 179.0.0.1 0 0 20 i
*> 192.168.1.0/24 1.152.0.1@0< 0 100 0 ?
```
You can also verify that the router `CENT1` receives the prefix `30.0.0.0/8` and
that the router `S1` receives the prefix `20.0.0.0/8`. To illustrate, here is a
the result of a `sh ip bgp` in the router `S1`, where we can see the prefix `20.0.0.0/8`.
```
S1_router# sh ip bgp
BGP table version is 3, local router ID is 179.0.1.2, vrf id 0
Default local pref 100, local AS 30
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/8 179.0.1.1 0 0 1 i
*> 20.0.0.0/8 179.0.1.1 0 1 i
*> 30.0.0.0/8 0.0.0.0 0 32768 i
```
Finally, you should be able to `ping` and `traceroute` from `S1-host` to `20.0.0.2`.
```
root@S1_host:/# traceroute 20.0.0.2 -n
traceroute to 20.0.0.2 (20.0.0.2), 30 hops max, 60 byte packets
1 30.101.0.2 0.036 ms 0.016 ms 0.014 ms
2 179.0.1.1 0.247 ms 0.244 ms 0.229 ms
3 * * *
4 1.0.2.1 0.681 ms 0.688 ms 0.664 ms
5 179.0.0.1 2.695 ms 2.698 ms 2.692 ms
6 20.0.0.2 2.926 ms 2.939 ms 2.908 ms
```
:warning: when you ping from the SWITCH network to the central branch of Credit Suisse,
make sure to ping from `S1-host` or from the router `CENT2`, otherwise the source IP
used in the ICMP Echo request will be `179.0.0...` and those IPs are not advertised
so there won't be an ICMP Echo reply.
R1 N\A L2-UBS1
R2 N\A L2-CS1
R1 N/A L2-UBS1
R2 N/A L2-CS1
R3 N/A L2-CS2
R4 N/A L2-UBS2
R5 N/A host:thomahol/d_host
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment