set up an "instantiation" of the container. This works somewhat similar to C++
templating, though much simpler.
-**In all following text, the Z prefix is replaced with a name choosen
+**In all following text, the Z prefix is replaced with a name chosen
for the instance of the datastructure.**
The common setup pattern will look like this:
should be installed in the rib based upon the originating protocol.
The lowest Admin Distance is the route selected. This is purely a
subjective decision about ordering and care has been taken to choose
-the same distances that other routing suites have choosen.
+the same distances that other routing suites have chosen.
+------------+-----------+
| Protocol | Distance |
here would be if someone else was running another routing suite besides
FRR at the same time, the kernel must choose what route to use to forward
on. FRR choose the value of 20 because of two reasons. FRR wanted a
-value small enough to be choosen but large enough that the operator could
+value small enough to be chosen but large enough that the operator could
allow route prioritization by the kernel when multiple routing suites are
being run and FRR wanted to take advantage of Route Replace semantics that
the linux kernel offers. In order for Route Replacement semantics to
nexthop via 192.168.161.9 dev enp39s0 weight 1
Once installed into the FIB, FRR currently has little control over what
-nexthops are choosen to forward packets on. Currently the Linux kernel
+nexthops are chosen to forward packets on. Currently the Linux kernel
has a ``fib_multipath_hash_policy`` sysctl which dictates how the hashing
algorithm is used to forward packets.
Display statistics about clients that are connected to zebra. This is
useful for debugging and seeing how much data is being passed between
- zebra and it's clients. If the summary form of the command is choosen
+ zebra and it's clients. If the summary form of the command is chosen
a table is displayed with shortened information.
.. clicmd:: show zebra router table summary