ipng/ipng.ch
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Replace all post_url with Hugo ref blocks

Browse Source
This commit is contained in:
Pim van Pelt
2024-08-05 01:43:55 +02:00
parent c1f1775c91
commit a2f10236a3
56 changed files with 221 additions and 241 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
content/articles/2022-04-02-vppcfg-2.md
View File

@ -8,10 +8,10 @@ title: VPP Configuration - Part2
# About this series
I use VPP - Vector Packet Processor - extensively at IPng Networks. Earlier this year, the VPP community
merged the [Linux Control Plane]({%post_url 2021-08-12-vpp-1 %}) plugin. I wrote about its deployment
to both regular servers like the [Supermicro]({%post_url 2021-09-21-vpp-7 %}) routers that run on our
[AS8298]({% post_url 2021-02-27-network %}), as well as virtual machines running in
[KVM/Qemu]({% post_url 2021-12-23-vpp-playground %}).
merged the [Linux Control Plane]({{< ref "2021-08-12-vpp-1" >}}) plugin. I wrote about its deployment
to both regular servers like the [Supermicro]({{< ref "2021-09-21-vpp-7" >}}) routers that run on our
[AS8298]({{< ref "2021-02-27-network" >}}), as well as virtual machines running in
[KVM/Qemu]({{< ref "2021-12-23-vpp-playground" >}}).
Now that I've been running VPP in production for about half a year, I can't help but notice one specific
drawback: VPP is a programmable dataplane, and _by design_ it does not include any configuration or
@ -102,7 +102,7 @@ dependencies, let me give a few examples:
## VPP Config: Ordering
In my [previous]({% post_url 2022-03-27-vppcfg-1 %}) post, I talked about a bunch of constraints that
In my [previous]({{< ref "2022-03-27-vppcfg-1" >}}) post, I talked about a bunch of constraints that
make certain YAML configurations invalid (for example, having both _dot1q_ and _dot1ad_ on a sub-interface,
that wouldn't make any sense). Here, I'm going to talk about another type of constraint: ***Temporal
Constraints*** are statements about the ordering of operations. With the example DAG above, I derive the
@ -448,7 +448,7 @@ needed, so it sets them all admin-state down. The bridge-domain `bd10` no longer
exist, the poor thing. But before it is deleted, the interface that was in `bd10` can be pruned
(membership _depends_ on the bridge, so in pruning, dependencies are removed before dependents).
Considering `Hu12/0/1.101` and `Gi3/0/0.100` were an L2XC pair before, they are returned to default
(L3) mode and because it's no longer needed, the [VLAN Gymnastics]({%post_url 2022-02-14-vpp-vlan-gym %})
(L3) mode and because it's no longer needed, the [VLAN Gymnastics]({{< ref "2022-02-14-vpp-vlan-gym" >}})
tag rewriting is also cleaned up for both interfaces. Finally, the sub-interfaces that do not appear
in the target configuration are deleted, completing the **pruning** phase.