1.1.1.0/24 via B distance 2 1.1.2.0/24 via B distance 1 1.1.3.0/24 via G distance 3 1.1.4.0/24 via G distance 2 1.2.1.0/24 local distance 0 1.2.2.0/24 via D distance 1 1.2.3.0/24 via G distance 1 1.2.4.0/24 via G distance 2
And C's FIB looks the same. If C has a packet with a destination in E such as 1.1.3.1, it will find the 1.1.3.0/24 entry and send the packet to G.
With geoaggregation, C's RIB looks like:
1.1.0.0/16 via B distance 1 1.1.0.0/16 via G distance 2 1.2.1.0/24 local distance 0 1.2.2.0/24 via D distance 1 1.2.3.0/24 via G distance 1 1.2.4.0/24 via G distance 2
C computes its FIB by selecting the best routes in the RIB:
1.1.0.0/16 next hop B 1.2.1.0/24 local 1.2.2.0/24 next hop D 1.2.3.0/24 next hop G 1.2.4.0/24 next hop G
If C has a packet with a destination in E such as 1.1.3.1, it will find the 1.1.0.0/16 entry and send the packet to B. But this is incorrect: D doesn't directly or indirectly pay B to transit his traffic. E isn't paying B to move his traffic either. B is paying for the link from B to C, so C is stealing bandwidth from his customer B in order to deliver a packet to E.
With geographically aggregated routing, neither G nor C have a route to E. They only see Left Area. That's the cause of the misroute. Even if you disaggregated and allowed G to see E (since E is paying for it), C would still route the packet to B because C wouldn't have a route for E, it would only have a route for Left Area.
Look, write out the announcements and compute the FIBs. You'll quickly see that what you're saying doesn't make any sense. The only way you can route according to who pays who is if you -don't- aggregate the routes according to the indicated geographies.
D paid C for connectivity B presumably has a relationship with C that allows traffic in that direction as well. Otherwise, C shouldn't be advertising that route to D or it should have a route in the other direction that it can use.
With BGP, C has a route for E advertised via G. With geographic aggregation, C has a route for "left area" which includes A, B, F and E. This route comes from both B and G. If the route to left area has priority via B then packets from D to E will improperly travel from C to B, ripping off B. If the route to left area has priority via G then packets from H to A will improperly travel from G to F, stealing bandwidth from F. That is an inescapable result of aggregating all of Left Area into a single route.
And it should be fairly obvious that unless B, C, F and G are reconnected into a strict hierarchy (which the so-called "valley free" path model defined by the business model on which the Internet functions does not permit) that result remains true.
The added complexity will be an issue, but will exist no matter what the routing scheme is.
No, actually, it won't.
The indirection map + encap approach, the the relatively small number of decapsulators follow the same rules as BGP does now while the destination address is mapped only to decapsulators with whom the destination has a business relationship. Map-encap doesn't lose the information about individual destinations so it doesn't suffer from geoaggregation's problem.
The dynamically addressed approach dynamically sets one or more addresses on each downstream host such that the host's address always accurately reflects its location within the business-defined topology. For example, in the diagram there are only two global routes: the one originating from C and the one originating from G. In addition, B advertises its subset of C's prefix to F as a shortcut while F advertises its subset of G to B as a shortcut. Plot the fibs on the diagram accordingly and you can see that those aggregated FIBs actually work both in terms of full connectivity and in terms of honoring the business relationships. But the price is that if A changes his connection to F then A always has to renumber, and if B buys a connection to F (instead of peering) the B and A have to manage -two- address blocks and assign two addresses to every host, one from the subset of addresses that originated with C and one for the subset that originated with G. And when one of those links fails, every downstream host has to respond by deprecating the corresponding address.
Which is very complex and eliminates the possibility of preserving the IPv6 versions of TCP and UDP, but it does not suffer the fault present in geographic aggregation.
Nodes A through H represent autonomous systems. The black lines indicate physical network connections. The blue circles represent geographic areas which you want to aggregate into a single global route. The green arrows indicate payment for service. (thus the green. Get it?) The black lines without green arrows are peering links.
If you construct the routes with normal BGP ignoring the geographic areas, all nodes can reach all other nodes and the packets will only travel peering links and links where there is a trail of green arrows from either the packet source node or the packet destination node. In other words, it accurately represents the business relationships that form the basis of the Internet's physical construction.
With geographically aggregated routes, the nodes in one circle see only a single route for all of the nodes in the other circle. No matter how you construct the forwarding information base (FIB) at each node, at least one of the following is true:
D routes to E via the B-C link (payment violation) H routes to A via the F-G link (payment violation) Some nodes can't reach other nodes.
The only way it functions without violating one of the company's networks is if B and F are the same company and C and G are the same company where from a payment perspective it doesn't matter which of the inter-geography links your packet transits to get to its destination.
So unfortunately when the IPNG guys back in 1998 thought they were going to solve the routing problem with hierarchical aggregation (which at least at one level is identical to geographic aggregation), it turned out they were in error about the feasibility. That really wrecked the whole routing plan for IPv6. The Regional Internet Registries are still adjusting to that reality, which is another drag on IPv6's deployment.
Actually, we've studied the routing by topology problem.
We've proven that routing by geography is not possible within the Internet transit business model, specifically geographical routing is only successful if there's only one backbone provider. Every geographic solution with more than one backbone has misroutes where packets transit links for which neither the sender nor the receiver has paid.
At this point, only two topological-oriented solutions have been found which hold out promise for a long term routing solution:
1. Map-encap (indirection). Large numbers of discontiguous addresses are mapped to topologically located exit-routers and then encapsulated into a packet addressed to that exit router. Once they reach the exit router, they're decapsulated and local routing takes over for final delivery. IPv6 offers no advantage in this approach versus IPv4.
2. Fully dynamic addressing in which the topologically based host address or addresses changes during operation to reflect changes in the network topology. This is wholly incompatible with IPv6's layer-4 protocols which require a stable layer-3 address in order to function.
#1 is a dirty hack and the closer we look the dirtier it gets. To make it clean, we'd need to design a layer-3 packet around the assumption of indirect routing with appropriate fields for the core ingress router to fill in plus headroom in the MTU so that the ingress router can expand the packet with transit information. IP header options don't work as it turns out. It's too hard to build hardware accelerators that can handle variable-length headers and when the source hosts get a packet too big message, they don't understand what to do about the additional IP options that they didn't put there.
In other words, we'd need to kick IPv6 to the curb.
#2 holds real promise but it means at least discarding IPv6's layer 4 protocols. Even if it keeps IPv6's layer 3 protocol there's absolutely no reason it can't also keep IPv4's layer-3 protocol at the same time (just as IPv4 and IPv6 run over multiple layer-2 protocols). If that were to happen, deployment of statically addressed IPv6 would end up being a waste of money that will require the same work and cost from both the folks who upgraded and the folks who didn't in order to deploy the new dynamically-addressed protocol.
See, the layer-4 protocols' reliance on the static-during-operation nature of the layer-3 address really limit the possible ways to route packets. The options are distance-vector (like BGP) and link-state (like OSPF). That's pretty much it; every other approach we've tried has unresolvable failure scenarios. Neither one is capable of an additional two orders of magnitude of growth.
What I was trying to impart was that the CPU/DRAM approach has been thoroughly studied by groups like the IRTF RRG and while there is a chance of successfully accommodating 10M BGP-style routes on a 10-year horizon given a $2B annual systemic investment, that's about the limit. If you don't believe me, set up a copy of Quagga on four five-end PCs with BGP in a line. A-B-C-D-E, each with a different AS. Announce 1M routes from E. Announce the same 1M routes with 5 ASes prepended from A. Now, disconnect E from D and measure how long it takes for B, C and D's routing table to stabilize.
Then, realize that with a 10M table there will be routine link failures that churn 1M routes in the nearby routers. And realize that Quagga is only handling the RIB portion of the routing table. A real router has to process both the RIB -and- the FIB, a much harder task.
This has been studied to death in places like the IRTF RRG. The bottom line is that 4B route BGP-style backbone is not achievable with any known or projected technology. If we want 4B routes or route-like elements, a monolithic-push distance-vector algorithm (like BGP) isn't going to do the job.
And if you still don't believe me, come to IETF 73 next month and sit in on the RRG sessions.
Step 1: Determine whether you're supposed to be teaching computer programming or computer literacy.
If Computer Literacy, rename the course and structure it accordingly. End.
Step 2: Where that myspace thing is on your computer monitor is computer literacy. Don't teach computer literacy.
You don't start a calculus course with a review of the multiplication tables. Any students who don't already know how to use a word processor and navigate the web are not ready for a programming course and don't belong in one. Catering to them will aggravate and waste the time of the students who -are- ready for a programming course.
Step 3: Pick one structured, strongly typed language like Pascal or Java. This is the -only- programming language you will be using in the course. Survey of programming languages comes much later, after the student knows how to program in a structured, strongly typed language.
Step 4: Go pirate one of the open content freshman CS courses from the colleges that publish them on the web. This is the content you will be teaching, only you'll want to stretch it out over a year instead of packing it into a semester. That should also give you some time to throw in some fun stuff of your own, but keep it parallel with the general lesson plan.
If you've set up your network so badly that a single link going down alters 4 Billion routes, you're doing it wrong!
What, are you dense? What do you think happens when you're an edge node multihomed with exactly two service providers and the link to one of them fails?
And if you can request a static, globally routable IP address for $5/month? Remember, you're in the 99th percentile of power users. Success with ISP-based NAT -doesn't- require that all clients be behind a NAT; it only requires that most clients be behind a NAT.
only problem is routers with anemic memory and CPU.
Wrong. Even with a fast CPU dedicated to only managing the routing table, it would take tens of minutes to process 4B BGP updates in response to a nearby link failure. The RAM simply can't change fast enough.
Also, while the speed limit for software-routed packets keeps increasing, it's still only passing through 750mbps. When you want to switch traffic between a dozen 10gbps interfaces, you have to move the task from software on a CPU to custom hardware.
One of the solutions is heavy parallelism that reduces individual data streams under the CPU limit. But then you have to maintain a full CPU and memory for the routing table for -each- CPU. Not 32G for the router, but 32G * 100.
Another is a TCAM: a special kind of memory. The individual cells are like SRAM but they're not addressed directly. Instead, all cells of the TCAM are activated on each lookup, and the TCAM spits out the row that has the best match. Not only is that expensive to build, its a power hog. A TCAM capable of handling a 4B entry routing table would draw something on the order of 5 to 10 kilowatts just to operate the TCAM.
Long term, the solution is a different kind of Internet Protocol, one which doesn't require a global route every time a hobbyist in his basement wants two ISPs. Some of the theoretical protocols allow multihoming of every home office plus mobility (which can look a lot like multihoming) with less than 50k global routes. Modern CPUs can easily keep up with changes to 50k routes and a TCAM which handles 50k routes is cheap to build and cheap to run.
Unfortunately, IPv6 is not such a protocol. IPv6 routes exactly the same way that IPv4 does with the additional detriment that it takes 4 times the TCAM capacity because the address is 4 times as long.
Stability version?
on
Linux 2.6.27 Out
·
· Score: 3, Interesting
When is the next stability-focused version (like 2.6.16) due out?
You could have made that argument about IPv4 in 1994.
Get your history right. By 1994, IPv4's deployment was a tremendous success, beggaring the deployment of any other unified data network in the world. Only the voice telephone network was more extensively deployed. Commercial use of the IPv4 Internet was restrained, barely, by NSF policy on the appropriate use of the federally funded backbone.
To find a time when things like x.25 or xns were still considered serious competitors to IPv4, you have to rewind to the late '80s.
A more accurate historical model for IPv6 may be the OSI protocol suite. It wouldn't be surprising since after OSI's failure in favor of IPv4, many of the same folks came back to design IPv6.
We cheaped out during our last hardware upgrade cycle so we'd have to upgrade everything this time around!
Well, that's the rub: if few others do, they don't have to. Quite the contrary: the ones in controlling positions like BT can cheer on their competitors IPv6 deployment because it drains their competitors cash. That means that next year they'll no longer be a competitor.
at the hardware level, I see no reason why any hardware equipment needs modification to support IPv6, unless you rely on "firmware-accelerated" hardware
100% of the network core uses firmware accelerated hardware. General purpose computers at the moment can't reliably move data much above 750mbps between multiple interfaces.
There is a small but growing number of folks who think IPv6 may be stillborn. The rationale goes something like this:
1. It's very expensive to upgrade an infrastructure of non-trivial size to IPv6 and that's only one of the several serious disincentives against deploying IPv6.
2. IPv6's rate of deployment to date can only be described as an abysmal commercial failure.
3. IPv6 fails to solve the Internet's core routing problem (reference the IRTF Routing Research Group). It's possible that a protocol which does solve that problem will leapfrog IPv6's deployment.
4. 2^32 addresses IS enough for everybody, IF most client computers are behind a NAT firewall. The count is too low only if most client computers need their own globally-routable address. That most client computers need their own globally-routable address is a dubious claim in light of today's wide deployment of NAT.
Hibernate mode in XP saves the state of the system to RAM and then maintains the RAM image even though the rest of the system is powered down.
Wrong! Hibernate saves the state to disk and powers down. "Stand By" saves the state to ram and then keeps the ram powered while everything else turns off.
New servers have 95 percent efficient power supplies
Wrong! Only a few power supplies are more than 85% efficient and none of the normal Dells or HPs you buy top 90%.
Power cycling healthy electronics is not a source of stress
Wrong! Anything that causes a rapid change in temperature is a source of stress. The materials expand and contract and different parts expand and contract at different rates. It's no different than the winter/summer cycle cracking the sidewalk.
Battery life for either type of battery can be prolonged greatly by removing the battery when the unit is plugged into AC power.
True, but an incredibly bad idea. The battery stabilizes current from the relatively crappy power brick. It can't do that if it isn't plugged in. And a single crash due to a power failure is likely to cost you more in the cost of your very valuable time than all the electricity you might save. Tis better to designate one battery your "docked" battery and make sure that when you're not recharging your travel batteries, you only your docked battery is connected.
If customers need to wait while you spin up cold spares to handle rising workload, brag about it.
What kind of crack are you smoking, and why haven't you shared?
There should never be a reason for someone to come in after 5pm if he's doing his job right.
Recently at work, the condensate drain on the computer room air conditioner got clogged and the water overflowed the pan around 1:00 am on a Saturday. No matter how good you are, the unexpected has a way of intruding at inconvenient times. As the sysadmin, you have to step in and deal with the problems when and where they happen.
If you're doing the job right, those times will be rare.
If you made it to the first interview then your background (in tech support) isn't the problem. The interviewer's time is worth too much to spend it interviewing the dozens of applicants whose background indicated a problem.
No, the problem is you. Either your presentation is poor (did you dress in a suit? conservative tie? do you smell? have open pustules? how long is your hair?), your mad computer engineering skillz don't add up to what you think they do OR (and this last one is very common) you didn't exhibit a can-do attitude.
Did you disdain your tech support background? It may be that the company is looking for a junior developer to interface with an upscale client, help with the testing, implement a little of the the easy stuff but mostly translate requirements for the senior devs. If you truly have the skills, that's as good a bridge as any. Better really: a cross-disciplinary role puts you in a controlling position, where your talent (if you have it) will shine.
The worst person I've ever interviewed explained that in a systems administration role there should never be a reason why he'd be expected to stay after 5 pm. The second worst explained that he was no stranger to keeping a cot in his office to deal with routinely long hours. The former indicated a bad attitude combined with poor judgment: an unrealistic assessment of a system administrator's job. The latter indicated a fellow who worked harder when I wanted someone to work smarter... a quality sysadmin prevents more fires than he fights. If you're fighting enough fires to need a cot in your office, you're not up to the task.
My favorite line in an interview is: "Point me at the problem that's giving you the most grief. I have a broad range of expertise and I'm ready to put it to use where it will best benefit you."
Yes, there is some reluctance to hire folks outside of their background. I recently made the transition from the systems administration track to software development track, so I've experienced it. Nevertheless, the only interview that didn't generate a job offer was one where the company specifically did not want a software developer.
With a few tweaks to make it acceptable to the enterprise instant messaging market, Cisco has a very salable product. Companies have been trying to kill off the AIM and Yahoo IM clients for some time because of the security risk they pose. They haven't succeeded because the enterprise IM clients don't meet an appropriate standard of quality and don't interact with anybody else's IM product.
Spore looked kinda neat. As a -casual- gamer, I mostly replay games I already own like Civ and the Ultimas. Some I've played for years on a progression of a dozen computers. I usually buy one or two new games each year and Spore looked like a fresh, innovative addition to my collection.
Then I heard about the DRM. No sale! I may eventually pirate it once its good and cracked, but I'm not in the habit of paying for the privilege of being hassled.
It means I decide whether I'm more worried about losing the password or more worried about getting hacked. If the latter, I choose a "gobbledygook" password and get very irritated when the site then asks for a "security question" which, if I were to follow the instructions and type in the name of my dog or the city in which I was born, would drastically reduce the level security offered from 62^L possibilities to a mere few thousand likely choices.
I don't mind if the site alerts me that my chosen password isn't very secure and I won't take offense at hints on how to make it better, but dammit if I choose a bad password anyway don't mess with me. And don't, don't, don't render the security meaningless with a "security question" that you had to resort to asking because your regular password rules were too complex for folks to deal with.
Someone went through the password recovery dialog and was able to guess answer "Where did you meet your spouse?".
What's with that anyway? Sites insist on a long gobbledygook password (God forbid we use something that doesn't have digits and capital letters) and then let us change the password by typing in something where a list of 100 covers about 99% of the answers. Just how stupid are these supposed security experts?
Congratulations: you've stumbled on a universal truth. Ideas are a dime a dozen. Folks who can bring ideas to life are very valuable.
So, whatever your idea is, it isn't so unique that there's no relevant mailing list on which to discuss it. Seriously, it just isn't. Go find the mailing list, lurk for a month or so until you get the feel of the place and then post a note laying out your vision.
I'll offer a word of advice though: don't waste your breath telling folks how simple your idea is. Your goal is to convince these folks to help you. There's nothing quite so insulting as telling someone that you're laying a trivial a trivial task on him because he wasn't bright enough to think of it himself and you can't be bothered to learn his worthless skill set so you could build it yourself. Seriously. Just lay out your vision. Let them tell you how easy or hard it is.
It is nice to see that domain name squatting works.
What's wrong with you that you can't take pleasure in another's good fortune?
For your information, the domain was a generic English word, the first one I registered from back in 1993, one of only 12 domains I held at the time and as it happens the one that I was using for my personal email and web site. I currently hold less, having sold the business associated with 6 of them, so the notion that I'm a domain squatter requires some serious sour grapes.
This happened to me back in 1999. Actually, it happened to me a lot, but 1999 was when I finally won the domain name lottery.
I told him the same thing I tell everyone who asks: "Well, I'm not really looking to sell my domain name but feel free to make me an offer."
He said, "I'll give you $5000."
I said, "That's a reasonable offer, but I have both the.com and the.org and I'd want to sell them as a pair."
He said, "Okay, I'll give you $5000 each."
I said, "That's a very fair offer. I need to think about what it would take me to change my address and migrate everything off the name."
A week later he called and asked for my decision. I said, "You made me a very fair offer. I'm still thinking it through. Give me a little more time."
A few days later he called and asked for my decision. I said, "You made me a very fair offer. I'm still thinking it through. Give me a little more time."
He said, "Look, I need to move forward, have graphics made for my business and so on. If you'll decide now, I'll double my offer."
I said, "Give me one hour. I'll call you back in an hour."
An hour later I said, "$20k? Done."
Down payment on my house, right before the real estate market headed for the sky.
The $600 A/C units both I and the poster are talking about sit entirely in the room. Air is drawn from the room, over the condenser and blown out of the room through a duct. For example: http://www.soleusair.com/soleusair/ph1_12r_03_c.html
This particular unit also has a "memory" so it starts back up after a power loss. This is particularly critical for a computer room.
Slashdot Mirror
Maybe it will make more sense to you if I explain it this way:
A: 1.1.1.0/24
B: 1.1.2.0/24
E: 1.1.3.0/24
F: 1.1.4.0/24
C: 1.2.1.0/24
D: 1.2.2.0/24
G: 1.2.3.0/24
H: 1.2.4.0/24
Left Area: 1.1.0.0/16
Right Area: 1.2.0.0/16
Using normal BGP, C's RIB looks like:
1.1.1.0/24 via B distance 2
1.1.2.0/24 via B distance 1
1.1.3.0/24 via G distance 3
1.1.4.0/24 via G distance 2
1.2.1.0/24 local distance 0
1.2.2.0/24 via D distance 1
1.2.3.0/24 via G distance 1
1.2.4.0/24 via G distance 2
And C's FIB looks the same. If C has a packet with a destination in E such as 1.1.3.1, it will find the 1.1.3.0/24 entry and send the packet to G.
With geoaggregation, C's RIB looks like:
1.1.0.0/16 via B distance 1
1.1.0.0/16 via G distance 2
1.2.1.0/24 local distance 0
1.2.2.0/24 via D distance 1
1.2.3.0/24 via G distance 1
1.2.4.0/24 via G distance 2
C computes its FIB by selecting the best routes in the RIB:
1.1.0.0/16 next hop B
1.2.1.0/24 local
1.2.2.0/24 next hop D
1.2.3.0/24 next hop G
1.2.4.0/24 next hop G
If C has a packet with a destination in E such as 1.1.3.1, it will find the 1.1.0.0/16 entry and send the packet to B. But this is incorrect: D doesn't directly or indirectly pay B to transit his traffic. E isn't paying B to move his traffic either. B is paying for the link from B to C, so C is stealing bandwidth from his customer B in order to deliver a packet to E.
With geographically aggregated routing, neither G nor C have a route to E. They only see Left Area. That's the cause of the misroute. Even if you disaggregated and allowed G to see E (since E is paying for it), C would still route the packet to B because C wouldn't have a route for E, it would only have a route for Left Area.
Look, write out the announcements and compute the FIBs. You'll quickly see that what you're saying doesn't make any sense. The only way you can route according to who pays who is if you -don't- aggregate the routes according to the indicated geographies.
D paid C for connectivity B presumably has a relationship with C that allows traffic in that direction as well. Otherwise, C shouldn't be advertising that route to D or it should have a route in the other direction that it can use.
With BGP, C has a route for E advertised via G. With geographic aggregation, C has a route for "left area" which includes A, B, F and E. This route comes from both B and G. If the route to left area has priority via B then packets from D to E will improperly travel from C to B, ripping off B. If the route to left area has priority via G then packets from H to A will improperly travel from G to F, stealing bandwidth from F. That is an inescapable result of aggregating all of Left Area into a single route.
And it should be fairly obvious that unless B, C, F and G are reconnected into a strict hierarchy (which the so-called "valley free" path model defined by the business model on which the Internet functions does not permit) that result remains true.
The added complexity will be an issue, but will exist no matter what the routing scheme is.
No, actually, it won't.
The indirection map + encap approach, the the relatively small number of decapsulators follow the same rules as BGP does now while the destination address is mapped only to decapsulators with whom the destination has a business relationship. Map-encap doesn't lose the information about individual destinations so it doesn't suffer from geoaggregation's problem.
The dynamically addressed approach dynamically sets one or more addresses on each downstream host such that the host's address always accurately reflects its location within the business-defined topology. For example, in the diagram there are only two global routes: the one originating from C and the one originating from G. In addition, B advertises its subset of C's prefix to F as a shortcut while F advertises its subset of G to B as a shortcut. Plot the fibs on the diagram accordingly and you can see that those aggregated FIBs actually work both in terms of full connectivity and in terms of honoring the business relationships. But the price is that if A changes his connection to F then A always has to renumber, and if B buys a connection to F (instead of peering) the B and A have to manage -two- address blocks and assign two addresses to every host, one from the subset of addresses that originated with C and one for the subset that originated with G. And when one of those links fails, every downstream host has to respond by deprecating the corresponding address.
Which is very complex and eliminates the possibility of preserving the IPv6 versions of TCP and UDP, but it does not suffer the fault present in geographic aggregation.
I'd like to know a bit more about that
Take a look at: http://bill.herrin.us/network/geoag.gif
Nodes A through H represent autonomous systems.
The black lines indicate physical network connections.
The blue circles represent geographic areas which you want to aggregate into a single global route.
The green arrows indicate payment for service. (thus the green. Get it?) The black lines without green arrows are peering links.
If you construct the routes with normal BGP ignoring the geographic areas, all nodes can reach all other nodes and the packets will only travel peering links and links where there is a trail of green arrows from either the packet source node or the packet destination node. In other words, it accurately represents the business relationships that form the basis of the Internet's physical construction.
With geographically aggregated routes, the nodes in one circle see only a single route for all of the nodes in the other circle. No matter how you construct the forwarding information base (FIB) at each node, at least one of the following is true:
D routes to E via the B-C link (payment violation)
H routes to A via the F-G link (payment violation)
Some nodes can't reach other nodes.
The only way it functions without violating one of the company's networks is if B and F are the same company and C and G are the same company where from a payment perspective it doesn't matter which of the inter-geography links your packet transits to get to its destination.
So unfortunately when the IPNG guys back in 1998 thought they were going to solve the routing problem with hierarchical aggregation (which at least at one level is identical to geographic aggregation), it turned out they were in error about the feasibility. That really wrecked the whole routing plan for IPv6. The Regional Internet Registries are still adjusting to that reality, which is another drag on IPv6's deployment.
Actually, we've studied the routing by topology problem.
We've proven that routing by geography is not possible within the Internet transit business model, specifically geographical routing is only successful if there's only one backbone provider. Every geographic solution with more than one backbone has misroutes where packets transit links for which neither the sender nor the receiver has paid.
At this point, only two topological-oriented solutions have been found which hold out promise for a long term routing solution:
1. Map-encap (indirection). Large numbers of discontiguous addresses are mapped to topologically located exit-routers and then encapsulated into a packet addressed to that exit router. Once they reach the exit router, they're decapsulated and local routing takes over for final delivery. IPv6 offers no advantage in this approach versus IPv4.
2. Fully dynamic addressing in which the topologically based host address or addresses changes during operation to reflect changes in the network topology. This is wholly incompatible with IPv6's layer-4 protocols which require a stable layer-3 address in order to function.
#1 is a dirty hack and the closer we look the dirtier it gets. To make it clean, we'd need to design a layer-3 packet around the assumption of indirect routing with appropriate fields for the core ingress router to fill in plus headroom in the MTU so that the ingress router can expand the packet with transit information. IP header options don't work as it turns out. It's too hard to build hardware accelerators that can handle variable-length headers and when the source hosts get a packet too big message, they don't understand what to do about the additional IP options that they didn't put there.
In other words, we'd need to kick IPv6 to the curb.
#2 holds real promise but it means at least discarding IPv6's layer 4 protocols. Even if it keeps IPv6's layer 3 protocol there's absolutely no reason it can't also keep IPv4's layer-3 protocol at the same time (just as IPv4 and IPv6 run over multiple layer-2 protocols). If that were to happen, deployment of statically addressed IPv6 would end up being a waste of money that will require the same work and cost from both the folks who upgraded and the folks who didn't in order to deploy the new dynamically-addressed protocol.
See, the layer-4 protocols' reliance on the static-during-operation nature of the layer-3 address really limit the possible ways to route packets. The options are distance-vector (like BGP) and link-state (like OSPF). That's pretty much it; every other approach we've tried has unresolvable failure scenarios. Neither one is capable of an additional two orders of magnitude of growth.
I apologize for the "dense" remark.
What I was trying to impart was that the CPU/DRAM approach has been thoroughly studied by groups like the IRTF RRG and while there is a chance of successfully accommodating 10M BGP-style routes on a 10-year horizon given a $2B annual systemic investment, that's about the limit. If you don't believe me, set up a copy of Quagga on four five-end PCs with BGP in a line. A-B-C-D-E, each with a different AS. Announce 1M routes from E. Announce the same 1M routes with 5 ASes prepended from A. Now, disconnect E from D and measure how long it takes for B, C and D's routing table to stabilize.
Then, realize that with a 10M table there will be routine link failures that churn 1M routes in the nearby routers. And realize that Quagga is only handling the RIB portion of the routing table. A real router has to process both the RIB -and- the FIB, a much harder task.
This has been studied to death in places like the IRTF RRG. The bottom line is that 4B route BGP-style backbone is not achievable with any known or projected technology. If we want 4B routes or route-like elements, a monolithic-push distance-vector algorithm (like BGP) isn't going to do the job.
And if you still don't believe me, come to IETF 73 next month and sit in on the RRG sessions.
Step 1: Determine whether you're supposed to be teaching computer programming or computer literacy.
If Computer Literacy, rename the course and structure it accordingly. End.
Step 2: Where that myspace thing is on your computer monitor is computer literacy. Don't teach computer literacy.
You don't start a calculus course with a review of the multiplication tables. Any students who don't already know how to use a word processor and navigate the web are not ready for a programming course and don't belong in one. Catering to them will aggravate and waste the time of the students who -are- ready for a programming course.
Step 3: Pick one structured, strongly typed language like Pascal or Java. This is the -only- programming language you will be using in the course. Survey of programming languages comes much later, after the student knows how to program in a structured, strongly typed language.
Step 4: Go pirate one of the open content freshman CS courses from the colleges that publish them on the web. This is the content you will be teaching, only you'll want to stretch it out over a year instead of packing it into a semester. That should also give you some time to throw in some fun stuff of your own, but keep it parallel with the general lesson plan.
If you've set up your network so badly that a single link going down alters 4 Billion routes, you're doing it wrong!
What, are you dense? What do you think happens when you're an edge node multihomed with exactly two service providers and the link to one of them fails?
I would rather not be behind an ISP's NAT.
And if you can request a static, globally routable IP address for $5/month? Remember, you're in the 99th percentile of power users. Success with ISP-based NAT -doesn't- require that all clients be behind a NAT; it only requires that most clients be behind a NAT.
only problem is routers with anemic memory and CPU.
Wrong. Even with a fast CPU dedicated to only managing the routing table, it would take tens of minutes to process 4B BGP updates in response to a nearby link failure. The RAM simply can't change fast enough.
Also, while the speed limit for software-routed packets keeps increasing, it's still only passing through 750mbps. When you want to switch traffic between a dozen 10gbps interfaces, you have to move the task from software on a CPU to custom hardware.
One of the solutions is heavy parallelism that reduces individual data streams under the CPU limit. But then you have to maintain a full CPU and memory for the routing table for -each- CPU. Not 32G for the router, but 32G * 100.
Another is a TCAM: a special kind of memory. The individual cells are like SRAM but they're not addressed directly. Instead, all cells of the TCAM are activated on each lookup, and the TCAM spits out the row that has the best match. Not only is that expensive to build, its a power hog. A TCAM capable of handling a 4B entry routing table would draw something on the order of 5 to 10 kilowatts just to operate the TCAM.
Long term, the solution is a different kind of Internet Protocol, one which doesn't require a global route every time a hobbyist in his basement wants two ISPs. Some of the theoretical protocols allow multihoming of every home office plus mobility (which can look a lot like multihoming) with less than 50k global routes. Modern CPUs can easily keep up with changes to 50k routes and a TCAM which handles 50k routes is cheap to build and cheap to run.
Unfortunately, IPv6 is not such a protocol. IPv6 routes exactly the same way that IPv4 does with the additional detriment that it takes 4 times the TCAM capacity because the address is 4 times as long.
When is the next stability-focused version (like 2.6.16) due out?
You could have made that argument about IPv4 in 1994.
Get your history right. By 1994, IPv4's deployment was a tremendous success, beggaring the deployment of any other unified data network in the world. Only the voice telephone network was more extensively deployed. Commercial use of the IPv4 Internet was restrained, barely, by NSF policy on the appropriate use of the federally funded backbone.
To find a time when things like x.25 or xns were still considered serious competitors to IPv4, you have to rewind to the late '80s.
A more accurate historical model for IPv6 may be the OSI protocol suite. It wouldn't be surprising since after OSI's failure in favor of IPv4, many of the same folks came back to design IPv6.
We cheaped out during our last hardware upgrade cycle so we'd have to upgrade everything this time around!
Well, that's the rub: if few others do, they don't have to. Quite the contrary: the ones in controlling positions like BT can cheer on their competitors IPv6 deployment because it drains their competitors cash. That means that next year they'll no longer be a competitor.
at the hardware level, I see no reason why any hardware equipment needs modification to support IPv6, unless you rely on "firmware-accelerated" hardware
100% of the network core uses firmware accelerated hardware. General purpose computers at the moment can't reliably move data much above 750mbps between multiple interfaces.
There is a small but growing number of folks who think IPv6 may be stillborn. The rationale goes something like this:
1. It's very expensive to upgrade an infrastructure of non-trivial size to IPv6 and that's only one of the several serious disincentives against deploying IPv6.
2. IPv6's rate of deployment to date can only be described as an abysmal commercial failure.
3. IPv6 fails to solve the Internet's core routing problem (reference the IRTF Routing Research Group). It's possible that a protocol which does solve that problem will leapfrog IPv6's deployment.
4. 2^32 addresses IS enough for everybody, IF most client computers are behind a NAT firewall. The count is too low only if most client computers need their own globally-routable address. That most client computers need their own globally-routable address is a dubious claim in light of today's wide deployment of NAT.
Hibernate mode in XP saves the state of the system to RAM and then maintains the RAM image even though the rest of the system is powered down.
Wrong! Hibernate saves the state to disk and powers down. "Stand By" saves the state to ram and then keeps the ram powered while everything else turns off.
New servers have 95 percent efficient power supplies
Wrong! Only a few power supplies are more than 85% efficient and none of the normal Dells or HPs you buy top 90%.
Power cycling healthy electronics is not a source of stress
Wrong! Anything that causes a rapid change in temperature is a source of stress. The materials expand and contract and different parts expand and contract at different rates. It's no different than the winter/summer cycle cracking the sidewalk.
Battery life for either type of battery can be prolonged greatly by removing the battery when the unit is plugged into AC power.
True, but an incredibly bad idea. The battery stabilizes current from the relatively crappy power brick. It can't do that if it isn't plugged in. And a single crash due to a power failure is likely to cost you more in the cost of your very valuable time than all the electricity you might save. Tis better to designate one battery your "docked" battery and make sure that when you're not recharging your travel batteries, you only your docked battery is connected.
If customers need to wait while you spin up cold spares to handle rising workload, brag about it.
What kind of crack are you smoking, and why haven't you shared?
There should never be a reason for someone to come in after 5pm if he's doing his job right.
Recently at work, the condensate drain on the computer room air conditioner got clogged and the water overflowed the pan around 1:00 am on a Saturday. No matter how good you are, the unexpected has a way of intruding at inconvenient times. As the sysadmin, you have to step in and deal with the problems when and where they happen.
If you're doing the job right, those times will be rare.
If you made it to the first interview then your background (in tech support) isn't the problem. The interviewer's time is worth too much to spend it interviewing the dozens of applicants whose background indicated a problem.
No, the problem is you. Either your presentation is poor (did you dress in a suit? conservative tie? do you smell? have open pustules? how long is your hair?), your mad computer engineering skillz don't add up to what you think they do OR (and this last one is very common) you didn't exhibit a can-do attitude.
Did you disdain your tech support background? It may be that the company is looking for a junior developer to interface with an upscale client, help with the testing, implement a little of the the easy stuff but mostly translate requirements for the senior devs. If you truly have the skills, that's as good a bridge as any. Better really: a cross-disciplinary role puts you in a controlling position, where your talent (if you have it) will shine.
The worst person I've ever interviewed explained that in a systems administration role there should never be a reason why he'd be expected to stay after 5 pm. The second worst explained that he was no stranger to keeping a cot in his office to deal with routinely long hours. The former indicated a bad attitude combined with poor judgment: an unrealistic assessment of a system administrator's job. The latter indicated a fellow who worked harder when I wanted someone to work smarter... a quality sysadmin prevents more fires than he fights. If you're fighting enough fires to need a cot in your office, you're not up to the task.
My favorite line in an interview is: "Point me at the problem that's giving you the most grief. I have a broad range of expertise and I'm ready to put it to use where it will best benefit you."
Yes, there is some reluctance to hire folks outside of their background. I recently made the transition from the systems administration track to software development track, so I've experienced it. Nevertheless, the only interview that didn't generate a job offer was one where the company specifically did not want a software developer.
With a few tweaks to make it acceptable to the enterprise instant messaging market, Cisco has a very salable product. Companies have been trying to kill off the AIM and Yahoo IM clients for some time because of the security risk they pose. They haven't succeeded because the enterprise IM clients don't meet an appropriate standard of quality and don't interact with anybody else's IM product.
Spore looked kinda neat. As a -casual- gamer, I mostly replay games I already own like Civ and the Ultimas. Some I've played for years on a progression of a dozen computers. I usually buy one or two new games each year and Spore looked like a fresh, innovative addition to my collection.
Then I heard about the DRM. No sale! I may eventually pirate it once its good and cracked, but I'm not in the habit of paying for the privilege of being hassled.
What exactly does password security mean to you?
It means I decide whether I'm more worried about losing the password or more worried about getting hacked. If the latter, I choose a "gobbledygook" password and get very irritated when the site then asks for a "security question" which, if I were to follow the instructions and type in the name of my dog or the city in which I was born, would drastically reduce the level security offered from 62^L possibilities to a mere few thousand likely choices.
I don't mind if the site alerts me that my chosen password isn't very secure and I won't take offense at hints on how to make it better, but dammit if I choose a bad password anyway don't mess with me. And don't, don't, don't render the security meaningless with a "security question" that you had to resort to asking because your regular password rules were too complex for folks to deal with.
Someone went through the password recovery dialog and was able to guess answer "Where did you meet your spouse?".
What's with that anyway? Sites insist on a long gobbledygook password (God forbid we use something that doesn't have digits and capital letters) and then let us change the password by typing in something where a list of 100 covers about 99% of the answers. Just how stupid are these supposed security experts?
Congratulations: you've stumbled on a universal truth. Ideas are a dime a dozen. Folks who can bring ideas to life are very valuable.
So, whatever your idea is, it isn't so unique that there's no relevant mailing list on which to discuss it. Seriously, it just isn't. Go find the mailing list, lurk for a month or so until you get the feel of the place and then post a note laying out your vision.
I'll offer a word of advice though: don't waste your breath telling folks how simple your idea is. Your goal is to convince these folks to help you. There's nothing quite so insulting as telling someone that you're laying a trivial a trivial task on him because he wasn't bright enough to think of it himself and you can't be bothered to learn his worthless skill set so you could build it yourself. Seriously. Just lay out your vision. Let them tell you how easy or hard it is.
It is nice to see that domain name squatting works.
What's wrong with you that you can't take pleasure in another's good fortune?
For your information, the domain was a generic English word, the first one I registered from back in 1993, one of only 12 domains I held at the time and as it happens the one that I was using for my personal email and web site. I currently hold less, having sold the business associated with 6 of them, so the notion that I'm a domain squatter requires some serious sour grapes.
This happened to me back in 1999. Actually, it happened to me a lot, but 1999 was when I finally won the domain name lottery.
I told him the same thing I tell everyone who asks: "Well, I'm not really looking to sell my domain name but feel free to make me an offer."
He said, "I'll give you $5000."
I said, "That's a reasonable offer, but I have both the .com and the .org and I'd want to sell them as a pair."
He said, "Okay, I'll give you $5000 each."
I said, "That's a very fair offer. I need to think about what it would take me to change my address and migrate everything off the name."
A week later he called and asked for my decision. I said, "You made me a very fair offer. I'm still thinking it through. Give me a little more time."
A few days later he called and asked for my decision. I said, "You made me a very fair offer. I'm still thinking it through. Give me a little more time."
He said, "Look, I need to move forward, have graphics made for my business and so on. If you'll decide now, I'll double my offer."
I said, "Give me one hour. I'll call you back in an hour."
An hour later I said, "$20k? Done."
Down payment on my house, right before the real estate market headed for the sky.
The $600 A/C units both I and the poster are talking about sit entirely in the room. Air is drawn from the room, over the condenser and blown out of the room through a duct. For example: http://www.soleusair.com/soleusair/ph1_12r_03_c.html
This particular unit also has a "memory" so it starts back up after a power loss. This is particularly critical for a computer room.