Skip to content

Commit

Permalink
more notes about the content of the tutorial
Browse files Browse the repository at this point in the history
  • Loading branch information
hellt committed Jul 23, 2024
1 parent c5c66ab commit 4c2b9fa
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 2 deletions.
2 changes: 1 addition & 1 deletion docs/tutorials/l3evpn/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ tags:

| | |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tutorial name** | L3 EVPN-VXLAN with SR Linux |
| **Tutorial name** | RT5-only L3 EVPN-VXLAN with SR Linux |
| **Lab components** | 3 SR Linux nodes, 2 [FRR](https://frrouting.org), 2 Alpine nodes |
| **Resource requirements** | :fontawesome-solid-microchip: 2vCPU <br/>:fontawesome-solid-memory: 8 GB |
| **Lab Repo** | [srl-l3evpn-basics-lab][lab-repo] |
Expand Down
2 changes: 2 additions & 0 deletions docs/tutorials/l3evpn/l3evpn-bgp-pe-ce.md
Original file line number Diff line number Diff line change
Expand Up @@ -373,6 +373,8 @@ The BGP on the Host model allows to advertise a range of prefixes from the host

At the same time, it requires a BGP speaker on the host, which may not be feasible in all environments and introduces another routing protocol and stack to the host. So, as always, evaluate the trade-offs and choose the model that fits your environment best.

With PE-CE protocol configured and BGP Add Path enabled, it is possible to achieve multuhoming and load balancing of the traffic between CE devices. The load balancing will be done purely on L3 level using ECMP where CE devices will advertise the same prefixes to the different leafs and therefore the remote CE devices will have multiple paths to reach the advertised prefixes.

We hope this was a fun configration marathon, and you enjoyed getting through this lab? Let's wrap it up with a quick [summary](summary.md).

<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>
10 changes: 9 additions & 1 deletion docs/tutorials/l3evpn/l3evpn.md
Original file line number Diff line number Diff line change
Expand Up @@ -232,7 +232,15 @@ Type 5 IP Prefix Routes

///

Brilliant, we receive the remote IP prefix `192.168.2.0/24` and sent local IP prefix `192.168.0.1/24` to the other leaf. Let's have a look at the routing table of IP-VRF on both leafs:
Brilliant, we receive the remote IP prefix `192.168.2.0/24` and sent local IP prefix `192.168.0.1/24` to the other leaf.

/// details | Route Summarization
In a real-world scenario, you would see more routes being exchanged, especially if you have multiple clients connected to the leaf switches. A good design practice is to summarize the routes on the leaf switches to reduce the number of routes exchanged between the leafs and the spine and mimimize the control plane churn when new host routes are added/removed.

Route summarization is not covered in this tutorial, but it should be not that complicated to add it!
///

Let's have a look at the routing table of IP-VRF on both leafs:

/// tab | leaf1

Expand Down

0 comments on commit 4c2b9fa

Please sign in to comment.