3 ms·

So what are they going to change as a consequence? It seems logical to not rely on a single router vendor anymore, or to test new rules on a staging setup at le

So what are they going to change as a consequence? It seems logical to not rely on a single router vendor anymore, or to test new rules on a staging setup at least for a very short time before pushing them to all routers.

rdl 14y ago
Running Vendor J and Vendor C routers together means you get exposed to the weird bugs in either's open/interoperability code, and lose out on all the advanced features (since most of the good stuff isn't well supported in true cross-platform vendor independent fashion). It's probably more reasonable to split your network into a few more independent sections and never do updates which affect everything, but unless you're building the space shuttle (and can accept vastly higher costs and lower performance), it's probably better to pick one hardware platform, at least now.
- eastdakota 14y ago
  While we'll discuss it more at length and after a bit of sleep, my hunch is this will be closer to our approach.
  - rdl 14y ago
    The thing which annoyed me the most was losing all DNS. You really need to have the DNS servers in separate infrastructure (ASN, netblock, while anycasted) so there is never a case where both of your DNS are out for a customer domain. The "CNAME" product looks pretty kludgey.
    - ams6110 14y ago
      By the same token you (the customer) should not have all your DNS eggs in one basket.
      - rincebrain 14y ago
        CloudFlare's CDN bits require you to give them DNS delegation of your stuff, last I looked.
        rdl 14y ago
        There is a way around it with some of the premium accounts, but it kind of seems like a hack.
jacques_chester 14y ago
Adding different vendor types creates a cartesian explosion of possible combinations of bugs. For standalone units that don't interact, n-version redundancy is good. But if they have to interact and somebody has to troubleshoot, n-version redundancy is a nightmare. The only reason it got fixed this quickly is because they had an intimate knowledge of a single vendor's products. That would be much more difficult with multiple vendors.

rdl 14y ago

Running Vendor J and Vendor C routers together means you get exposed to the weird bugs in either's open/interoperability code, and lose out on all the advanced features (since most of the good stuff isn't well supported in true cross-platform vendor independent fashion). It's probably more reasonable to split your network into a few more independent sections and never do updates which affect everything, but unless you're building the space shuttle (and can accept vastly higher costs and lower performance), it's probably better to pick one hardware platform, at least now.

eastdakota 14y ago
While we'll discuss it more at length and after a bit of sleep, my hunch is this will be closer to our approach.
- rdl 14y ago
  The thing which annoyed me the most was losing all DNS. You really need to have the DNS servers in separate infrastructure (ASN, netblock, while anycasted) so there is never a case where both of your DNS are out for a customer domain. The "CNAME" product looks pretty kludgey.
  - ams6110 14y ago
    By the same token you (the customer) should not have all your DNS eggs in one basket.
    - rincebrain 14y ago
      CloudFlare's CDN bits require you to give them DNS delegation of your stuff, last I looked.
      - rdl 14y ago
        There is a way around it with some of the premium accounts, but it kind of seems like a hack.

jacques_chester 14y ago

Adding different vendor types creates a cartesian explosion of possible combinations of bugs. For standalone units that don't interact, n-version redundancy is good. But if they have to interact and somebody has to troubleshoot, n-version redundancy is a nightmare. The only reason it got fixed this quickly is because they had an intimate knowledge of a single vendor's products. That would be much more difficult with multiple vendors.