Re: ouch..
On 9/14/2011 10:41 AM, Leigh Porter wrote: On Wed, 2011-09-14 at 08:33 -0500, N. Max Pierson wrote: Either way, it's pathetic. If someone is going to slander in the fashion the site has done, they should at least put a contact form somewhere for some feedback :) Slander means falsehood. Cisco tells lies ? Lies? So who has 100G MX series cards then..? That's disingenuous. The question was not whether Cisco has ever lied, but whether the web page lies. The web page very carefully picks and chooses facts, but I don't think it actually lies. Therefore, it isn't slander. It's just mudslinging. Also, on another note, nobody should be surprised that the registration information doesn't say "Cisco." Think about it: would they want "whois overpromisesunderdelivers.com" to say "Cisco" all over it?
Re: Microsoft deems all DigiNotar certificates untrustworthy, releases
On 9/13/2011 10:29 AM, Tei wrote: *a random php programmer shows* He, I just want to self-sign my CERT's and remove the ugly warning that browsers shows. I don't want to pay 1000$ a year, or 1$ a year for that. I just don't want to use cleartext for internet data transfer. HTTP is like telnet, and HTTPS is like ssh. But with ssh is just can connect, with browsers theres this ugly warning and "fuck you, self-signed certificate" from the browsers. Please make the pain stop!. With ssh, you will get a warning if the remote host key is not known, with a fingerprint and advice not to accept it if you don't know if it is correct. This is a direct analog to the warning that the remote host's certificate cannot be verified. In both cases, you are given the chance to accept the key/certificate and continue going; depending on the implementation, you might also be given the option to accept it once or forever. Ssh is actually prone to bigger, uglier, more explicit "you probably don't want to trust this" warnings, especially about things like key changes.
Re: NAT444 or ?
On 9/7/2011 3:24 PM, Seth Mos wrote: I think you have the numbers off, he started with 1000 users sharing the same IP, since you can only do 62k sessions or so and with a "normal" timeout on those sessions you ran into issues quickly. Remember that a TCP session is defined not just by the port, but by the combination of source address:source port:destination address:destination port. So that's 62k sessions *per destination* per ip address. In theory, this particular performance problem should only arise when the NAT gear insists on a unique port per session (which is common, but unnecessary) or when a particular destination is inordinately popular; the latter problem could be addressed by increasing the number of addresses that facebook.com and google.com resolve to. I'm not advocating CGN; my point is not that this problem *should* be solved, merely that it *can* be. -Dave
Re: Route Optimization Software / Appliance
This is basically Arbinet's "Optimized" product; it uses actual measurements for loss, round trip time, and jitter to choose routes. Right now, it is just sold as a service, going through the providers they sell access to; I don't know if you could purchase/license the software for your own use. -Dave (Full disclosure: Arbinet is my current employer.) On 8/22/2011 1:27 PM, Babak Pasdar wrote: Hello Group, I was wondering if anyone could share their experience with any route optimization approaches, methodologies or platforms, either open source or commercial (Internap FCP), that can actively adjust BGP parameters based on latency and number of layer 3 hops to a network rather than AS hops. We have upstreams all over the country and we would like to automate optimization to take the best egress path. Thank you for your feedback in advance. Best Regards, Babak -- Babak Pasdar President& CEO | Certified Ethical Hacker Bat Blue Corporation | Integrity . Privacy . Availability . Performance (p) 212.461.3322 x3005 | (f) 212.584. | (w) www.BatBlue.com Bat Blue is proud to be the Official WiFi Provider for ESPN's X Games Bat Blue's AS: 25885 | BGP Policy | Peering Policy Receive Bat Blue's Daily Security Intelligence Report Bat Blue's Legal Notice
Re: IPv6 day non-participants
On 6/8/2011 6:18 PM, Patrick W. Gilmore wrote: On Jun 8, 2011, at 12:49 PM, George B. wrote: Was participating until we hit a rather nasty load balancer bug that took out the entire unit if clients with a short MTU connected and it needed to fragment packets (Citrix Netscaler running latest code). No fix is available for it yet, so we had to shut it down. Ran for about 9 hours before the "magic" client that blew it up connected. So if you are using a Netscaler with SLB-PT (IPv6 VIP balancing to IPv4 servers), the entire LB is subject to stop working until they get this fixed. And this is EXACTLY why we needed World IPv6 Day. It is also probably why doing it again next month is too aggressive, and why we probably should have started doing them earlier. I wonder how many bug reports got filed today? -Dave
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
On 2/17/2011 1:31 PM, Jeffrey Lyon wrote: IPv6's momentum is a lot like a beach landing at Normandy. As in, "large, dedicated, and nigh unstoppable, but fraught with peril and with a lot of mess and destruction to get through before it is done," or as in "mainly opposed by aging crazy Nazis who should have seen it coming but kept their attention in the wrong place?"
Re: quietly....
On 2/15/2011 5:08 AM, Iljitsch van Beijnum wrote: On 14 feb 2011, at 6:46, Frank Bulk wrote: Requiring them to be on certain well known addresses is restrictive and creates an unnecessary digression from IPv4 practice. It's comments like this that raise the hair on admins' necks. At least mine. I don't get this. Why spend cycles discovering a value that doesn't need to change? Because it will change. At some point, this paradigm will shift. The service hierarchy will change, the protocol methodology will change, the network topology will change... *something* will happen that will make a well-known address, hard-coded in a million places, change from a boon to a massive headache. One of the biggest problem v6 seems to have had is that its designers seemed to think the problem with v4 was that it didn't have enough features. They then took features from protocols that ipv4 had killed over the years, and added them to v6, and said, "Look, I made your new IP better." And then, when the operators groaned and complained and shook their heads, the ipv6 folks called them "backward" and "stuck in ipv4-think." But the fact of the matter is, operators want a protocol to be as simple, efficient, flexible, and stupid as possible. They don't want the protocol tied to how things work today; it needs to be open to innovation and variety. And part of that is that an address needs to be just an address, with no other significance other than being unique and routable. The moment an address has any significance beyond the network layer, it's a liability waiting to happen.
Re: Introducing draft-denog-v6ops-addresspartnaming
On 11/19/2010 4:57 AM, George Bonser wrote: It's always two bytes, but people may choose to omit them. That is a social, not a (purely) technical, syntax, though. Richard That's exactly what I was going to say but didn't want to quibble. We tend to call them "quads" at work. What do you call that indeterminate space between two colons :: where it might be four or more zeros in there? That's a bunch of nibbles, maybe a "gulp"? Yeah, I think I'd quibble with quibble; it's antagonistic. "Gulp" has serious potential in casual conversation (especially because you can refer to the excluded "::" portion as "the Big Gulp") but somehow I don't see it used in technical documentation. I like "morsel," personally. (Well, I also like "collop," because it's arcane and sounds vaguely dirty to me, but I don't think that would catch on.)