I think your dreaming if you think any company can release fully bug free software every go?
But a company can have a battery of tests that they run every new release against to ensure nothing broke. Every time an issue is reported you add it to the test battery. After a while you have a huge number of tests that are ran. These can either be executed by a human (tedius, error prone), or by automation. The more difficult issues are ones that take time to appear, or require complicated triggers, but when you have access to the internal state of the router, you can devise tests that look for anomalies, which might appear much sooner than it would manifest itself externally. Also, you could have a device which sits in the network and snoops on OSPF and/or BGP, DCHP, and other protocols and flags anything that doesn't look proper.
Basically, you need someone who's job it is to reproduce reported issues, and design/build generalized tests for them that you can run against all your products that run said software.
On the more long-term, don't introduce errors to start with front,
a technique that is helpful is design-by-contract, which unfortunately, most programming languages don't support or encourage.
Design-by-contract can also be used in deployed stuff, and when implemented properly can catch an error immediately and point the finger directly at the component (and specific part of that component) that is to blame, which usually makes fixing the problem simple. This can be used on products in the field, where said error could be reported to the log and a corrective action of some sort taken (such as generating an autosupout with details of the problem, and restarting DHCP, for hypothetical example). In areas where performance is critical design-by-contract can even be selectively enabled/disabled. (i.e. you notice some problem with your router, turn on "detect/report errors" feature, and reboot the router and wait til it happens again, or make it happen again).
However, design-by-contract is so effective that errors are almost always caught immediately in internal testing/development, and it can be disabled in deployed software (but shouldn't be, except in performace critical sections, unless you're sure your internal testing methodology tests every possible code path).
This all of course is easier written than done; but just because most companies may not do it, there are in fact techniques to produce error free products, but virtual 100% error free is usually more expense than dealing with the consequences of an error unless you're producing nuclear reactors/weapons or medical devices or other human-life related products (like airplanes), or spacecraft where a truck-roll isn't feasible or VERY expensive (not that some medical device and spacecraft companies haven't tried to cut corners anyway).
The Art Of Computer Programming also talks about techniques that can be used to produce error-free software.
Common-sense says you can't produce bug-free software. Common-sense says the world is flat.
Both are wrong.