From 362d07893c09d134e9ea33cf799b693d984ad0d3 Mon Sep 17 00:00:00 2001 From: Larry Peterson Date: Mon, 20 Jul 2026 15:04:54 -0700 Subject: [PATCH 1/2] elevated DHCP to section Signed-off-by: Larry Peterson --- operations.rst | 1 + operations/config.rst | 162 ++++++--------------------------------- operations/dhcp.rst | 115 +++++++++++++++++++++++++++ operations/telemetry.rst | 16 ++-- operations/velocity.rst | 2 +- 5 files changed, 147 insertions(+), 149 deletions(-) create mode 100644 operations/dhcp.rst diff --git a/operations.rst b/operations.rst index 18e4f97..e90941d 100644 --- a/operations.rst +++ b/operations.rst @@ -47,6 +47,7 @@ when something goes wrong, troubleshoot the cause of that failure, and then take corrective action. .. include:: operations/design.rst +.. include:: operations/dhcp.rst .. include:: operations/config.rst .. include:: operations/telemetry.rst .. include:: operations/velocity.rst diff --git a/operations/config.rst b/operations/config.rst index 2bc94f4..407b3cf 100644 --- a/operations/config.rst +++ b/operations/config.rst @@ -4,148 +4,30 @@ .. index:: YAML: YAML Ain't Markup Language .. index:: gNMI: gRPC Network Management Interface .. index:: gNOI: gRPC Network Operations Interface -.. index:: DHCP: Dynamic Host Configuration Protocol .. index:: YANG: Yet Another Next Generation -|Ops|.2 Configuration Management --------------------------------------- +|Ops|.3 Network Configuration +----------------------------------- -This section looks at the configuration side of the operations -problem, with a focus on the protocols, interfaces, data models, and -open source tools commonly used to build a network management system. -Every network adopts its own operational practices, so there is no -single solution we can point to. There are some broad trends among the -large cloud operators that we use to illustrate the approaches to -configuration management. We use cloud operators as our exemplar -because they are pushing the boundaries of automation, which we expect -to become more widely adopted over time. Keeping in mind this is a -partial view of the full landscape of operational practices, we -conclude this section with a brief introduction to another example -toolset. +We now turn our attention to the more general problem of configuring +all the switches and routers—plus the software they run—inside the +network. Our focus is on the protocols, interfaces, data models, and +open source tools that are commonly used. Every network adopts its +own operational practices, so there is no single solution we can point +to. But there are some broad trends among the large cloud operators +that we use to illustrate the approaches to configuration +management. We use cloud operators as our exemplar because they are +pushing the boundaries of automation, which we expect to become more +widely adopted over time. Keeping in mind this is a partial view of +the full landscape of operational practices, we conclude this section +with a brief introduction to another example toolset. -|Ops|.2.1 Host Configuration +|Ops|.3.1 Configuration Interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We start with a bootstrapping step that happens any time you open your -laptop and hope to connect to Wi-Fi: -acquiring an IP address. While this might seem like a problem to be -addressed in Part III, where we take up issues at the edge of the -network, assigning IP addresses is the responsibility of the network. -It is also an operational problem in that sense that IP addresses are -a kind of resource that needs to be managed. Either we find a way to -automate the solution, or an operator (system admin) has to do it -manually, on a case-by-case basis. - -We have already seen one example of the network assigning IP address -to connected devices, and that was in Section |Shared|.4.3, where we -described how Mobile Cellular network authenticates UEs. For the rest -of the Internet, the Dynamic Host Configuration Protocol (DHCP), is -the mechanism that implements address assignment. DHCP is actually -more general, in that it is used to configure other parameters hosts -need to successfully send and receive packets; for example, their -subnet mask, default router, and DNS server. (Remember that a -machine's Ethernet address is typically burned into the NIC, but its -IP address depends on what network it tries to connect to.) - -It's worth noting that DHCP wasn't part of the original Internet's -design. IP address configuration was a manual step in the early years, -and it was only as the Internet started to spread to home networks and -small offices without IT staff -that the need for autoconfiguration became sufficiently pressing to -lead to the development of DHCP. - -DHCP relies on the existence of a DHCP server to provide configuration -information to hosts. There is at least one DHCP server for an -administrative domain. At the simplest level, this server implements a -centralized repository for host configuration information, so in -principle, a network administrator could maintain a static list of -address assignments on this server. Each host could then contact the -server when it boots up, and retrieve its configuration. In this -model, the configuration information for each host is stored in a -table that is indexed by some form of unique client identifier, -typically the hardware address (e.g., the Ethernet address of its -network adaptor). - -A more sophisticated use of DHCP saves the network administrator from -even having to assign addresses to individual hosts. In this model, the -DHCP server maintains a pool of available addresses that it hands out to -hosts on demand. This considerably reduces the amount of configuration -an administrator must do, since now it is only necessary to allocate a -range of IP addresses (all with the same network number) to each -network. - -Since the goal of DHCP is to minimize the amount of manual -configuration required for a host to function, it would rather defeat -the purpose if each host had to be configured with the address of a -DHCP server. Thus, the first problem faced by DHCP is that of server -discovery. - -To contact a DHCP server, a newly booted or attached host sends a -``DHCPDISCOVER`` message to a special IP address (255.255.255.255) -that is an IP broadcast address. This means it will be received by all -hosts and routers on that network. (Routers do not forward such -packets onto other networks, preventing broadcast to the entire -Internet.) In the simplest case, one of these nodes is the DHCP server -for the network. The server would then reply to the host that -generated the discovery message (all the other nodes would ignore -it). However, it is not really desirable to require one DHCP server on -every network, because this still creates a potentially large number -of servers that need to be correctly and consistently configured. -Thus, DHCP uses the concept of a *relay agent*. There is at least one -relay agent on each network, and it is configured with just one piece -of information: the IP address of the DHCP server. When a relay agent -receives a ``DHCPDISCOVER`` message, it unicasts it to the DHCP server -and awaits the response, which it will then send back to the -requesting client. The process of relaying a message from a host to a -remote DHCP server is shown in :numref:`Figure %s `. - -.. _fig-dhcp-relay: -.. figure:: operations/figures/f03-24-9780123850591.png - :width: 500px - :align: center - - A DHCP relay agent receives a broadcast DHCPDISCOVER - message from a host and sends a unicast DHCPDISCOVER to the DHCP - server. - -:numref:`Figure %s ` below shows the format of a DHCP -message, which is sent using UDP. Note that DHCP was derived from an -earlier protocol called BOOTP, and some of the packet fields are thus -not strictly relevant to host configuration. When trying to obtain -configuration information, the client puts its hardware address (e.g., -its Ethernet address) in the ``chaddr`` field. The DHCP server replies -by filling in the ``yiaddr`` (“your” IP address) field and sending it -to the client. Other information such as the default router to be used -by this client can be included in the ``options`` field. - -.. _fig-dhcp: -.. figure:: operations/figures/f03-25-9780123850591.png - :width: 400px - :align: center - - DHCP packet format. - -In the case where DHCP dynamically assigns IP addresses to hosts, it -is clear that hosts cannot keep addresses indefinitely, as this would -eventually cause the server to exhaust its address pool. At the same -time, a host cannot be depended upon to give back its address, since -it might have crashed, been unplugged from the network, or been turned -off. Thus, DHCP allows addresses to be leased for some period of -time. Once the lease expires, the server is free to return that -address to its pool. A host with a leased address needs to renew the -lease periodically if in fact it is still connected to the network and -functioning correctly. - -|Ops|.2.2 Configuration Interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -DHCP targets the configuration problem at the boundary between the -network and the hosts that connect to the network. We now turn our -attention to the more general problem of configuring all the switches -and routers—plus the software they run—inside the network. As outlined -in the previous section, the core problem is to define the set of -variables available for operators to ``GET`` and ``SET`` on these +As outlined in Section |Ops|.1, the core problem is to define the set +of variables available for operators to ``GET`` and ``SET`` on these devices, with the additional requirement that this dictionary of variables should be uniform across devices (i.e., be vendor-agnostic). We also need an over-the-wire protocol to remotely invoke these @@ -372,7 +254,7 @@ upgrade the device, for example, by installing the latest version of BGP. .. literalinclude:: operations/code/system.proto -|Ops|.2.3 Configuration-as-Code +|Ops|.3.2 Configuration-as-Code ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As soon as you scale the network—for example, to the size of a @@ -443,7 +325,7 @@ repo holds the latest executable images for the software stack running on each device (e.g., the latest release of OSPF or BGP). For now, we assume an upstream provider, for example a vendor, populates the image repo. We'll look at how the pipeline extends to the left to account -for networks that also build their own software in Section |Ops|.4. +for networks that also build their own software in Section |Ops|.5. .. _fig-config-pipeline: .. figure:: operations/figures/config-pipeline.png @@ -455,8 +337,8 @@ for networks that also build their own software in Section |Ops|.4. and executable images supplied by an upstream vendor. -|Ops|.2.4 Other Toolsets -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +|Ops|.3.3 Other Tools +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This chapter describes how to design a management system as a top-down exercise, and while it is true that cloud operators have taken a @@ -508,7 +390,7 @@ with the system described earlier in this section, although it ends up being more bespoke than off-the-shelf. This makes it more cumbersome to maintain and evolve. -.. This last paragraph is a candidate Takeaway +.. TODO -- This last paragraph is a candidate Takeaway A lesson illustrated by this example is that there is no single right set of tools for any problem space. Instead, you typically start with diff --git a/operations/dhcp.rst b/operations/dhcp.rst new file mode 100644 index 0000000..9b11bf3 --- /dev/null +++ b/operations/dhcp.rst @@ -0,0 +1,115 @@ +.. index:: DHCP: Dynamic Host Configuration Protocol + +|Ops|.2. Host Configuration +----------------------------------- + +Before getting to the general problem of network configuration, we +start with a bootstrapping step that happens any time you open your +laptop and hope to connect to Wi-Fi: acquiring an IP address. While +this might seem like a problem to be addressed in Part III, where we +take up issues at the edge of the network, assigning IP addresses is +the responsibility of the network. It is also an operational problem +in that sense that IP addresses are a kind of resource that needs to +be managed. Either we find a way to automate the solution, or an +operator (system admin) has to do it manually, on a case-by-case +basis. + +We have already seen one example of the network assigning IP address +to connected devices, and that was in Section |Shared|.4.3, where we +described how Mobile Cellular network authenticates UEs. For the rest +of the Internet, the Dynamic Host Configuration Protocol (DHCP), is +the mechanism that implements address assignment. DHCP is actually +more general, in that it is used to configure other parameters hosts +need to successfully send and receive packets; for example, their +subnet mask, default router, and DNS server. (Remember that a +machine's Ethernet address is typically burned into the NIC, but its +IP address depends on what network it tries to connect to.) + +It's worth noting that DHCP wasn't part of the original Internet's +design. IP address configuration was a manual step in the early years, +and it was only as the Internet started to spread to home networks and +small offices without IT staff +that the need for autoconfiguration became sufficiently pressing to +lead to the development of DHCP. + +DHCP relies on the existence of a DHCP server to provide configuration +information to hosts. There is at least one DHCP server for an +administrative domain. At the simplest level, this server implements a +centralized repository for host configuration information, so in +principle, a network administrator could maintain a static list of +address assignments on this server. Each host could then contact the +server when it boots up, and retrieve its configuration. In this +model, the configuration information for each host is stored in a +table that is indexed by some form of unique client identifier, +typically the hardware address (e.g., the Ethernet address of its +network adaptor). + +A more sophisticated use of DHCP saves the network administrator from +even having to assign addresses to individual hosts. In this model, the +DHCP server maintains a pool of available addresses that it hands out to +hosts on demand. This considerably reduces the amount of configuration +an administrator must do, since now it is only necessary to allocate a +range of IP addresses (all with the same network number) to each +network. + +Since the goal of DHCP is to minimize the amount of manual +configuration required for a host to function, it would rather defeat +the purpose if each host had to be configured with the address of a +DHCP server. Thus, the first problem faced by DHCP is that of server +discovery. + +To contact a DHCP server, a newly booted or attached host sends a +``DHCPDISCOVER`` message to a special IP address (255.255.255.255) +that is an IP broadcast address. This means it will be received by all +hosts and routers on that network. (Routers do not forward such +packets onto other networks, preventing broadcast to the entire +Internet.) In the simplest case, one of these nodes is the DHCP server +for the network. The server would then reply to the host that +generated the discovery message (all the other nodes would ignore +it). However, it is not really desirable to require one DHCP server on +every network, because this still creates a potentially large number +of servers that need to be correctly and consistently configured. +Thus, DHCP uses the concept of a *relay agent*. There is at least one +relay agent on each network, and it is configured with just one piece +of information: the IP address of the DHCP server. When a relay agent +receives a ``DHCPDISCOVER`` message, it unicasts it to the DHCP server +and awaits the response, which it will then send back to the +requesting client. The process of relaying a message from a host to a +remote DHCP server is shown in :numref:`Figure %s `. + +.. _fig-dhcp-relay: +.. figure:: operations/figures/f03-24-9780123850591.png + :width: 500px + :align: center + + A DHCP relay agent receives a broadcast DHCPDISCOVER + message from a host and sends a unicast DHCPDISCOVER to the DHCP + server. + +:numref:`Figure %s ` below shows the format of a DHCP +message, which is sent using UDP. Note that DHCP was derived from an +earlier protocol called BOOTP, and some of the packet fields are thus +not strictly relevant to host configuration. When trying to obtain +configuration information, the client puts its hardware address (e.g., +its Ethernet address) in the ``chaddr`` field. The DHCP server replies +by filling in the ``yiaddr`` (“your” IP address) field and sending it +to the client. Other information such as the default router to be used +by this client can be included in the ``options`` field. + +.. _fig-dhcp: +.. figure:: operations/figures/f03-25-9780123850591.png + :width: 400px + :align: center + + DHCP packet format. + +In the case where DHCP dynamically assigns IP addresses to hosts, it +is clear that hosts cannot keep addresses indefinitely, as this would +eventually cause the server to exhaust its address pool. At the same +time, a host cannot be depended upon to give back its address, since +it might have crashed, been unplugged from the network, or been turned +off. Thus, DHCP allows addresses to be leased for some period of +time. Once the lease expires, the server is free to return that +address to its pool. A host with a leased address needs to renew the +lease periodically if in fact it is still connected to the network and +functioning correctly. diff --git a/operations/telemetry.rst b/operations/telemetry.rst index c7d28e9..2fc0e7b 100644 --- a/operations/telemetry.rst +++ b/operations/telemetry.rst @@ -1,7 +1,7 @@ .. index:: INT: Inband Network Telemetry .. index:: NDT: Network Diagnostic Tool -|Ops|.3 Monitoring and Telemetry +|Ops|.4 Monitoring and Telemetry -------------------------------------- There are many potential sources of telemetry data. This section looks @@ -15,10 +15,10 @@ logs to ensure that their implementations of OSPF, BGP, and so on, are correct, but once in the hands of a network operator, metrics and traces are the most common way to monitor whether or not the network is operating properly and to diagnose problems. We revisit this -assumption in Section |Ops|.4, when we look at more rapidly evolving +assumption in Section |Ops|.5, when we look at more rapidly evolving network functionality. -|Ops|.3.1 OpenConfig Metrics +|Ops|.4.1 OpenConfig Metrics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A good place to start is the OpenConfig models described in the @@ -27,7 +27,7 @@ variables (those with ``rw`` permissions) and variables that devices use to report local metrics back to the central management system (those with ``ro`` permissions). For example, the following code snippet expands on the ``counter`` variable for Ethernet interfaces -shown in Section |Ops|.2.2: +shown in Section |Ops|.3.2: .. literalinclude:: operations/code/counters.yang @@ -75,7 +75,7 @@ you (a) what information is worth collecting, and (b) what values or changes in values are worth acting on. -|Ops|.3.2 Traffic Analysis +|Ops|.4.2 Traffic Analysis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Counting the number of packets sent/received by a given interface is a @@ -207,7 +207,7 @@ displays of the collected data. |TLS|. -|Ops|.3.3 Active Monitoring +|Ops|.4.3 Active Monitoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The preceding examples of telemetry data are all based on *passive @@ -252,7 +252,7 @@ connection). `Measurement Lab `__. -|Ops|.3.4 In-Band Network Telemetry +|Ops|.4.4 In-Band Network Telemetry ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We conclude this discussion of telemetry by returning to the weakest @@ -292,7 +292,7 @@ packet, and records the corresponding data for each switch. .. _fig-int: .. figure:: operations/figures/int.png - :width: 700px + :width: 650px :align: center Illustration of Inband Network Telemetry (INT), with each packet diff --git a/operations/velocity.rst b/operations/velocity.rst index daa24ad..ac83801 100644 --- a/operations/velocity.rst +++ b/operations/velocity.rst @@ -1,6 +1,6 @@ .. index:: CI/CD: Continuous Integration / Continuous Deployment -|Ops|.4 Feature Velocity +|Ops|.5 Feature Velocity -------------------------------------- We have seen many examples in this chapter of how cloud operations From f2a10e4b8e77ba6f41baaba7afad8566607f452c Mon Sep 17 00:00:00 2001 From: Bruce Davie <3101026+drbruced12@users.noreply.github.com> Date: Tue, 21 Jul 2026 13:36:30 +1000 Subject: [PATCH 2/2] minor wording tweaks Signed-off-by: Bruce Davie <3101026+drbruced12@users.noreply.github.com> --- operations/config.rst | 8 ++++---- operations/design.rst | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/operations/config.rst b/operations/config.rst index 407b3cf..2c47153 100644 --- a/operations/config.rst +++ b/operations/config.rst @@ -58,7 +58,7 @@ and 1213, respectively, and if you want to follow the history of incremental refinements, there is a long list of follow-on RFCs. But all of this work is based on an approach that pre-dates the availability of modern modeling languages, of which YANG has become -the widely-accepted solution. YANG—which stands for *Yet Another Next +the widely-accepted solution. YANG stands for *Yet Another Next Generation*, a name chosen to poke fun at how often a do-over proves necessary. YANG defines the structure of the data, and is general enough to be used in conjunction with different over-the-wire message @@ -102,7 +102,7 @@ formats, including XML, YAML, JSON, and Protocol Buffers (protobufs). need a companion language that is used to define the schema, or data model, for the information being represented. For XML, that companion language is XSD (XML Schema Definition). For YAML, YANG - is commonly used (although YANG can also be used for other markup + is commonly used (although YANG can also be used for other languages, including XML). There are technical differences between XSD and YANG—and what each is able to model—but those details are beyond the scope of this discussion.* @@ -112,13 +112,13 @@ defines the semantics of the variables available to be read and written, is available in a programmatic form; it’s not just text in a standards document. But a modeling language is no better than the models it defines, and this has proven problematic due to conflicting -incentives. Network operators that buy network hardware have a strong +incentives. Network operators who buy network hardware have a strong incentive to drive the models for similar devices towards convergence, so they are not locked into products from a single vendor. Vendors, on the other hand, have an equally strong incentive to emphasize the uniqueness of their products. This results in a fragmented set of models. YANG makes the process of creating, using, and modifying -models programmable and hence, adaptable to an iterative process. The +models programmable and hence adaptable to an iterative process. The only question is whether the industry can successfully iterate towards convergence. diff --git a/operations/design.rst b/operations/design.rst index 4391240..e338e38 100644 --- a/operations/design.rst +++ b/operations/design.rst @@ -169,8 +169,8 @@ practice is sometimes described in exactly those terms: including parameters that allow the device to take advantage of other services (e.g., NTP, Syslog, SMTP, NFS), as well as setting the parameters this device needs to perform whatever service it - provides. At the end of Day-1 operationalization, the device is - considered up-and-running, and able to support user traffic. + provides. At the end of Day 1 operationalization, the device is + considered up and running, and able to support user traffic. * **Day 2..N:** On-going management in support of day-to-day operations, coupled with monitoring the network to detect failures