Re: Link capacity upgrade threshold
On Sun, 30 Aug 2009, Nick Hilliard wrote: In order to get a really good idea of what's going on at a microburst level, you would need to poll as often as it takes to fill the buffer of the port in question. This is not feasible in the general case, which is why we resort to hacks like QoS to make sure that when there is congestion, it is handled semi-sensibly. Or some enterprising vendor could start recording utilisation stats? regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Try to value useful qualities in one who loves you.
Re: DNS hardening, was Re: Dan Kaminsky
On Thu, 6 Aug 2009, Florian Weimer wrote: This doesn't seem possible with current SCTP because the heartbeat rate quickly adds up and overloads servers further upstream. It also does not work on UNIX-like system where processes are short-lived and get a fresh stub resolver each time they are restarted. Stubs on Unix systems can have long-lived processes that handle the actual lookups, the stub component in the process that calls into the resolver then accesses it via IPC. I.e. the NSCD style approach. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: As Zeus said to Narcissus, Watch yourself.
RE: one shot remote root for linux?
On Tue, 28 Apr 2009, Gregory Boehnlein wrote: It is a common misconception that the ESX Hypervisor is Linux based, but that is an urban legend. Is the ESX Hypervisor useful without the Linux layer? Then, to what extent do based on and depends on differ in the context of software? --paulj
Re: one shot remote root for linux?
On Thu, 30 Apr 2009, Andre Gironda wrote: ESXi doesn't require much Linux (just busybox), but I think the point is that the VMkernel (the hypervisor) and the service console (Linux) are separate entities. The SC is really a VM, so it depends more on VMkernel than VMkernel depends on it. So it's a VM, which is required to be booted in order to be able to load the hypervisor? Seems an unusual definition of VM to me.. Also, which code handles the I/O to load the other, less special, VMs? The Linux fs and block layer, or the VMWare hypervisor? Anyway, I fear we're about to be kicked into touch by the moderators.. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)]
On Thu, 5 Feb 2009, Matthew Moyle-Croft wrote: DHCP(v6). Setting the idea in people's heads that a /64 IS going to be their own statically is insane and will blow out provider's own routing tables more than is rational. Routing table size will be a function of the number of customers - *not* the prefix length assigned to them (for so long as address space is sufficiently sparsely allocated that there's a 1:1 mapping from customer to prefix - which should be for a long time with IPv6). So (within that longer term constraint) it doesn't matter if you're allocating your customer a /48, /56 or /64. Indeed, what you're suggesting - smaller-than-64 allocations - *would* increase routing table sizes. With your proposal those indexes would increase greatly in depth (and possibly other space increases due to not being able to optimise for hierarchical routing of bits past 64 is highly rare). Think of IPv6 as a 64bit network address + host address. At least for now. regards, -- Paul Jakma p...@clubi.ie p...@jakma.org Key ID: 64A2FF6A Fortune: If you don't have a nasty obituary you probably didn't matter. -- Freeman Dyson
Re: Hardware capture platforms
On Fri, 1 Aug 2008, Paul Jakma wrote: GigE is PtP at the physical-layer by the IEEE 802.3ad specification. It's Gah, I meant 802.3ab, of course. just not possible to have a dumb, GigE hub. You have to have a switch that can be told to L2-forward everything to one or more ports (e.g. through a port-mirroring feature, or by disabling MAC learning). Also, though probably not terribly relevant, various switches have various bugs/malfeatures that cause them to consume certain kinds of frames rather than forward them (e.g. consuming all or certain kinds of ISO frames). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Anything is possible, unless it's not.
Re: Hardware capture platforms
On Wed, 30 Jul 2008, Jon Kibler wrote: However, there is a problem with your specification: No hub (that I am aware of) can do 1Gbps. All hubs are 10/100 AFAIK. GigE is PtP at the physical-layer by the IEEE 802.3ad specification. It's just not possible to have a dumb, GigE hub. You have to have a switch that can be told to L2-forward everything to one or more ports (e.g. through a port-mirroring feature, or by disabling MAC learning). Also, though probably not terribly relevant, various switches have various bugs/malfeatures that cause them to consume certain kinds of frames rather than forward them (e.g. consuming all or certain kinds of ISO frames). regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: lisp, v.: To call a spade a thpade.
