Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> most firewall configs are broken

If we just accept "networks are unreliable and sometimes broken" as a fact of life, things will never get better. I applaud the unsung heroes who are finding and fixing the actual root causes of lower layers of our networks. Other important networking issues that come to mind are bufferbloat and IPv6 brokenness.

I'm sure it will be fixed if this stays on the front page for a while, so be sure to upvote the article.



>If we just accept "networks are unreliable and sometimes broken" as a fact of life, things will never get better. I applaud the unsung heroes who are finding and fixing the actual root causes of lower layers of our networks.

As developers, this should always be a fact of life. True, we should strive for making the networks perfect, but at the end of the day, these things still need to be accounted for.

Because you don't have control over a client deciding that 50 cent network cards are "good enough" for their deployment even though they've demanded five 9's uptime from your software.

Because you can't know when someone's going to spill beer on the switch.

Because someone's just going to pull the wrong cable.

Because the water company accidentally cut the line into the building.


Right, but if PMTUD is broken, basically large transfers to clients with low MTU don't and never will work, and there's not much you can do about it.

It's not like it's an "unreliable connection" which can be worked around with error correction. It's a "broken connection", which needs to be fixed.


You're mostly talking about reliability at the physical layer, which as you say is never going to be perfect. Csense is talking about reliability at the link layer and above, which is infinitely more attainable.


That's kind of my point, though.

If you can't guarantee that every layer below you is absolutely reliable, then you need to assume that everything below you might be broken, and that you need to handle it. You can't start with the mindset that everything works below you, and have everything above you also work fine.

The fact that we have people with the mindset that everything below them is broken is the entire reason that these kinds of issues get detected and fixed.


Yeah if you try and work around broken PMTUD though you're going to mess up your application layer protocol SO bad...

EDIT: I suppose you could rewrite TCP MSS on your own firewall or drop MTU on all web servers.... but of course if you're going to reconfigure your firewall / intefaces, you may as well just fix the problem - which was caused by poor device configuration in the first place.


You also can't know when someone between you and the other endpoint has configured something stupidly. :)

As a sysadmin, I do my best to make the network as damn near perfect as possible; but as a developer, I still generally assume the network is unreliable and plan accordingly.


I think it SHOULD be accepted as a fact of life. That way we can then learn to improve our designs of applications and processes to be more tolerant to network faults and unreliability, which is a good thing.


IPv6 brokenness?


Here's an example that affected me just a few days ago:

http://www.datacenterknowledge.com/archives/2009/10/22/peeri...

Basically, Hurricane Electric and Cogent (two major transit providers) are refusing to exchange IPv6 traffic. That breaks stuff. For me the problem manifested as a user facing a 20 second delay whenever he ssh'd in (over IPv4). (I'm on Hurricane Electric. The reverse DNS for his IPv4 address is served by Cogent DNS servers. Reverse DNS lookups were trying to access the Cogent name server over IPv6 and had to time out before IPv4 was tried.)

Other than that though, I actually haven't encountered very much IPv6 breakage.


Peering disputes are nothing new though. I was a Level 3 and Cogent customer, and suddenly my two servers couldn't talk anymore ...

Peering disputes are problematic for both IPv4 and IPv6. This has nothing at all to do with the IP version!

(p.s. You do realise that the article you linked to is from 2009 ...)


Has any IPv4 peering dispute lasted this long? (Yes, the article is from 2009. They're still locked in a dispute in 2012.)


No, mainly because it would be business suicide for whoever is involved. Especially if neither party is willing to pay for transit to the other... IPv6 is still small enough that it doesn't yet force one providers hand over the other.

That being said, if you are single homed on HE only then I would suggest you purchase transit elsewhere as well, or find a datacenter that has multiple transit providers. Being single home is dangerous.

The real question is going to be how long can Cogent hold-out. HE is willing to provide them free IPv6 peering, why not accept it so that their customers can get a full IPv6 table...


Presumably the failure of some to jump onto the IPv6 bandwagon? I guess we can expect IPv4 to stick around like IE6 for a while.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: