Skip to content

Commit 4c2b9fa

Browse files
committed
more notes about the content of the tutorial
1 parent c5c66ab commit 4c2b9fa

File tree

3 files changed

+12
-2
lines changed

3 files changed

+12
-2
lines changed

docs/tutorials/l3evpn/index.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ tags:
99

1010
| | |
1111
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
12-
| **Tutorial name** | L3 EVPN-VXLAN with SR Linux |
12+
| **Tutorial name** | RT5-only L3 EVPN-VXLAN with SR Linux |
1313
| **Lab components** | 3 SR Linux nodes, 2 [FRR](https://frrouting.org), 2 Alpine nodes |
1414
| **Resource requirements** | :fontawesome-solid-microchip: 2vCPU <br/>:fontawesome-solid-memory: 8 GB |
1515
| **Lab Repo** | [srl-l3evpn-basics-lab][lab-repo] |

docs/tutorials/l3evpn/l3evpn-bgp-pe-ce.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -373,6 +373,8 @@ The BGP on the Host model allows to advertise a range of prefixes from the host
373373

374374
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.
375375

376+
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.
377+
376378
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).
377379

378380
<script type="text/javascript" src="https://viewer.diagrams.net/js/viewer-static.min.js" async></script>

docs/tutorials/l3evpn/l3evpn.md

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -232,7 +232,15 @@ Type 5 IP Prefix Routes
232232

233233
///
234234

235-
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:
235+
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.
236+
237+
/// details | Route Summarization
238+
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.
239+
240+
Route summarization is not covered in this tutorial, but it should be not that complicated to add it!
241+
///
242+
243+
Let's have a look at the routing table of IP-VRF on both leafs:
236244

237245
/// tab | leaf1
238246

0 commit comments

Comments
 (0)