3 ms·

You can't really blame Juniper for these crashes. They released a fix for the issue months ago. These customers must not have upgraded. See the juniper software

You can't really blame Juniper for these crashes. They released a fix for the issue months ago. These customers must not have upgraded. See the juniper software alert here: http://pastebin.com/HBWiH92j http://pastebin.com/HBWiH92j

trout 15y ago
Can't really blame a manufacturer for a bug that crashes routers by easily passed BGP parameters? It's not possible it's their fault this wasn't caught in dev-test? I've seen many environments where it's a multi-year process to roll out new code, particularly in service providers. I wouldn't classify asking a service provider to change all their code in a matter of months a reasonable request. The amount of testing they do before rolling code is very time consuming. It's not uncommon for service providers to run on 3-4-5 year old code.
- eyeareque 15y ago
  Running 3-5 year old code shows that the provider/company probably doesn't prioritize or fund testing as well as they should IMO. I'm sure Juniper would work with any company who asked for a patch or custom work around if they cannot upgrade now. I see your point, Juniper missed a serious bug in their testing. But you can't hold them completely accountable when they've already announced and released a fix that corrects the issue.
  - marshray 15y ago
    The problem is, by releasing the patch they alert attackers to the existence of the bug. I don't know this to be the case here, but for things like Windows vulnerabilities the time between releasing the patch and it being exploited in the wild is only a few hours. For systems (like core routers) that are simultaneously too critical and too available to permit timely maintenance cycles, the only solution is to not have any bugs ever.
    - baq 15y ago
      good luck with that. if something is too critical to be taken offline, it should have a hot standby, right?
  - salem 15y ago
    The bulletin is 3 months old. I would find it surprising if they updated their core router firmware that often, and even if they did, it's probably with a version that is already several months old and has been through lab testing and small scale test deployment. A bulletin like that would have likely reset the cycle.
salem 15y ago
You could also say that this is a situation Cisco and Juniper have created. In the past, they have not been great at delivering good quality software. Some still say that Cisco's version 1 is really a beta. This has created a culture of caution at ISPs where they have had to create their own long acceptance testing procedures, causing long periods between updates.

trout 15y ago

Can't really blame a manufacturer for a bug that crashes routers by easily passed BGP parameters? It's not possible it's their fault this wasn't caught in dev-test? I've seen many environments where it's a multi-year process to roll out new code, particularly in service providers. I wouldn't classify asking a service provider to change all their code in a matter of months a reasonable request. The amount of testing they do before rolling code is very time consuming. It's not uncommon for service providers to run on 3-4-5 year old code.

eyeareque 15y ago
Running 3-5 year old code shows that the provider/company probably doesn't prioritize or fund testing as well as they should IMO. I'm sure Juniper would work with any company who asked for a patch or custom work around if they cannot upgrade now. I see your point, Juniper missed a serious bug in their testing. But you can't hold them completely accountable when they've already announced and released a fix that corrects the issue.
- marshray 15y ago
  The problem is, by releasing the patch they alert attackers to the existence of the bug. I don't know this to be the case here, but for things like Windows vulnerabilities the time between releasing the patch and it being exploited in the wild is only a few hours. For systems (like core routers) that are simultaneously too critical and too available to permit timely maintenance cycles, the only solution is to not have any bugs ever.
  - baq 15y ago
    good luck with that. if something is too critical to be taken offline, it should have a hot standby, right?
- salem 15y ago
  The bulletin is 3 months old. I would find it surprising if they updated their core router firmware that often, and even if they did, it's probably with a version that is already several months old and has been through lab testing and small scale test deployment. A bulletin like that would have likely reset the cycle.

salem 15y ago

You could also say that this is a situation Cisco and Juniper have created. In the past, they have not been great at delivering good quality software. Some still say that Cisco's version 1 is really a beta. This has created a culture of caution at ISPs where they have had to create their own long acceptance testing procedures, causing long periods between updates.