Not only configuration, but even monitoring falls under this umbrella. Customers are free to standardize on the model and tools such as CollectD, Graphite, and Ganglia to gather statistics for all their data center equipment. All of these tools have active communities that are developing and extending these tools continuously. Also, they can use tools such as Monit to monitor the processes and take actions based on events such as restarting the daemon if a protocol daemon dies.
Second, using the Linux API unmodified means that customers can pick and choose which protocol suites they want to in their network. For example, two popular routing protocol suites are Quagga and BIRD. Since they both rely on the well-established netlink API to modify the routing table and understand when interfaces go up or down, they can run unmodified on the networking gear. Even customer-specific protocols or protocol suites can run as long as they adhere to the standard API. The same applies to other protocols such as LLDP (Link-Layer Discovery Protocol) and STP (Spanning-Tree Protocol).
Next, problems such as defining API to program a box, what tables to program, what is the model of the box, and so on are all rendered irrelevant because Linux has an open, well-established model and API. An active community is also invested in ensuring the integrity of this API.
Moreover, the open nature of Linux means customers can be involved in developing their own tools to solve their specific problems. For example, instead of relying on the networking vendor to develop features such as link state tracking or flex links, customers can download and use nifty utilities such as Netplug or ifplugd. Tools such as Netcat can be used to pull info from multiple devices in the network.
Another benefit for customers is that the open nature of this model provides unprecedented (for a router/switch) transparency. For example, they can verify there are no backdoors in the code.
This openness also means a vibrant community is actively involved in innovating solutions. For example, in the server world, Linux containers have emerged as a lightweight alternative to server virtualization, and a whole new set of tools are being developed to use this. The networking world can now be a part of this innovation rather than something that is innovated around. For example, instead of using real boxes, customers can test their network deployment using VMs or containers and push the configuration to real networks only after this is passed.
Am I talking of using x86-based servers as routers? No, I'm talking about a model where Linux can function as described above, but the network data path is hardware accelerated. In other words, the switching silicon is added to the list of hardware that Linux already manages, such as processors and memory devices.