{"id":714,"date":"2017-04-27T00:00:00","date_gmt":"2017-04-27T00:00:00","guid":{"rendered":"https:\/\/nl1g1e2381-staging.onrocket.site\/seeking-truth-in-networking-from-testing-to-verification\/"},"modified":"2025-02-19T10:08:47","modified_gmt":"2025-02-19T18:08:47","slug":"seeking-truth-in-networking-from-testing-to-verification","status":"publish","type":"post","link":"https:\/\/www.forwardnetworks.com\/blog\/2017\/04\/27\/seeking-truth-in-networking-from-testing-to-verification\/","title":{"rendered":"Seeking Truth in Networking: From Testing To Verification"},"content":{"rendered":"\n

Sharp network admins already verify<\/em> the network in a variety of ways, right? Pings, traceroutes, and custom scripts verify <\/em>expected connectivity. Link and CPU utilization monitoring programs verify<\/em> normal operation. Maybe pushed configs are read back in to verify<\/em> that the device accepted them. And isn\u2019t verification just another term for testing, anyway?<\/p>\n\n\n\n

No. Just like data ain\u2019t knowledge, testing ain\u2019t verification!<\/strong><\/p>\n\n\n\n

In this blog post, you\u2019ll see how stories from other technology domains (like semiconductors and software) point toward verification as a natural next step in any critical environment, especially one like networking.<\/p>\n\n\n\n

Learning from history: verification in other domains<\/strong><\/h3>\n\n\n\n

Computer Hardware<\/strong><\/p>\n\n\n\n

Manufacturing the next great computer chip begins with producing a mask set \u2013 a stack of extremely detailed circuit patterns \u2013 which is then used to etch circuits onto a silicon wafer. If a mistake slips into the circuit design and is discovered in the lab, a new mask set is required. This is a big<\/strong> deal! A single bad mask set can cost millions of dollars and delay a product\u2019s introduction.<\/p>\n\n\n\n

But even worse is when a bug escapes the lab and customers find it. Remember the Intel Pentium FDIV bug<\/a>? A rare but easy-to-replicate math error would corrupt data. Recalling and replacing the affected processors cost Intel nearly $500M.<\/p>\n\n\n\n


It\u2019s not as if Intel didn\u2019t test their chip in advance. Skilled engineers wrote unit tests to confirm the expected behavior of their own circuits, created integration tests to confirm the behavior of entire modules, and ran extensive test patterns in the lab. But it\u2019s extremely hard to think of every test worth running.<\/p>\n\n\n\n

What if \u2013 instead of having more people write more tests and yet still have to cross their fingers \u2013 we could write a program that would know<\/em> whether the chip logic was correct, to avoid any errors like FDIV corruption?<\/p>\n\n\n\n

Such programs exist under the category of verification<\/em>. One particular verification technique, called model checking, could have helped avoid the FDIV error<\/a>. It works by representing circuit states in a graph and checking all possible transitions; the trick is to do this fast enough and on large enough circuits. In fact, this development was so important that it led to a Turing award<\/a> for its creators.<\/p>\n\n\n\n

Verification techniques can\u2019t prevent chip fabrication errors and won\u2019t design the chip for you, but they provide extremely valuable assurance that you can\u2019t get any other way.<\/p>\n\n\n\n

Computer Software<\/strong><\/p>\n\n\n\n

In the software world, correctness is just as important, especially when a bug has real real-world effects. Think software that operates an airport baggage system<\/a>, controls a radiation dosage<\/a>, or guides a rocket into space, like on June 4, 1996, when the Ariane 5 rocket made its maiden voyage to space.<\/p>\n\n\n\n

\n