After the swap over the pc wouldn't boot, would reset before any screen output. Refresh install time thinks I. In goes the original media. Type in my original product key. All seems ok: great I think; job done. And then I log in to check for updates… Wtf? I'm not activated?

So now I find myself with another reinstall in the works. I do have another key I can use for this pc, but its for a different install cd and won't work with the oem cd I used to repair last night.

I guess thats my point. I did a repair last night, not a full install on a new pc. It kept all my other settings, why not my activation?

I'm glad I only run one windows box on the network at home. don't have any of these issues with the OSX, Debian or Ubuntu boxes.

Microsoft, I know you are not listening, but here's a suggestion. The main reason you have such a stranglehold on the os market is because your OS has the apps support, and your own apps are a large part of that. Make windows free. You'd kill Linux as a desktop contender just like making IE free killed Netscape as the dominant browser.

Of course, as a longterm Microsoft hater I don't want this to happen; I love that modern linux distros such as Ubuntu or SuSE make an open source desktop viable for non unix geeks; however in my mind it seems like a plausible option for them to take and a surefire way of killing the opposition. Sure they'd lose the revenue from new pc installs, they'd still have their apps though, they could still get revenue from the specialised variants (embedded, server, 3+ Cpu) and most of all they would get rid of the headaches of having to figure out new ways to stop OS piracy without generating extra support overhead when it breaks existing customer installs. It'd get rid of almost all of the bad press about MS too; very little of the bad press is about their office productivity apps. A lot of it is about oppressive os licensing. They'd still catch flack for their DRM stance and the crappy standards compliance in Internet Explorer (I gave up trying to make my sites display properly in IE ages ago; why should I work harder because MS don't read the standards properly before writing their code?). IE7 is supposedly more standards compliant. I don't want to get started on that though, I'll just say this: Why does fixing a bug require a major upgrade? Would it really be that hard to backport the fixed standards compliance as a critical update for 6 so webmasters don't have to wait years for everyone to update?

I was going to do some reading on the train this morning after a quick post. I seem to have got carried away...

This article was started because I thought this aproach was flat out wrong; however during the research I managed to convince myself that it is the almost the right thing to do; just needs a couple of knobs to tweak to make it flexible enough to always do the right thing.

Ok, so we have our reason for the network eatering the table. What will happen if we just pass the network unchanged? Depending on the policies of your peers they will either drop the route at their boundary, causing lack of global reach for your customer, or they will pass it on, and it'll eventually be spotted, your network will be ridiculed, your peers will lose respect, your wife will run off with the circus and you'll be left broken and alone with nothing for company but a broken toaster. Don't do it. Burnt toast is bad.

We have a prefix originating from a private AS. It would be bad to pass that on to other peers. So what do we do?

A quick look at the documentation provides us with a contender: remove-private-as on cisco, remove private on Juniper. Both statements have the same effect: they strip private autonomous system numbers from outbound advertisements.

Brief interlude from RFC4271

5.1.2 AS_PATH

1. When a given BGP speaker advertises the route to an internal peer, the advertising speaker SHALL NOT modify the AS_PATH attribute associated with the route.
2. When a given BGP speaker advertises the route to an external peer, the advertising speaker updates the AS_PATH … [by] prepend[ing] its own AS number…

RFC4271 section 5.1.2 as I read it explicitly disallows modifying the as path when advertising to an ibgp peer; however there is nothing I could find in the standard that explicitly disallows such modifications when advertising to external peers. This gives the vendors the loophole they need.

The problem is that in order to set up a private as peer you need to configure all other peers to remove private as numbers. While this works, and seems to be the generally accepted RightThing™ to do, it just doesn't quite sit right with me; I like policy to be applied once at the entry to the network, not at every exit point.

Another problem comes when you have multiple private as peers.

The whole reason for storing the as path in BGP is to prevent loops (not as a distance vector, even if that is how implementations use it). The reason we are considering the implications of removing part of the as path in the first place is because the customer is multi-homed. Turning off a safeguard when you have exactly the topology it was designed to protect is a bad idea.

What about other private as peers? Remove-private doesn't allow fine tuning. If you allow one private as you allow them all, so if you have multiple customers connected and you advertise their private as numbers to each other you are violating the principals of keeping the numbers private. If one of the customers is using private as numbers internally then routes may get dropped due to non existant loops, and the support desk get calls due to connectivity problems. I admit it isn't likely, but its possible so will probably happen.

A route-map/policy would help:

router bgp 1234
  neighbor 1.2.3.4 remote-as 65534
  neighbor 1.2.3.4 remove-private-as route-map as65534-out
!
ip as-path access-list 1 permit ^(6553[234])_
!
route-map as65534-out deny 10
 match as-path 1
route-map as65534-out permit 20

Conclusions.

Peering with customers using private as numbers is a useful tool and has a number of valid applications, but starting it is like opening pandoras box. Be aware that you are operating in a grey area outside the standards. Here be dragons.

Hang on... All my tag clouds are actually bulleted list without any weighting. Surely there must be a way to fix that?

taglevel<$MTTagRank$>

Now to style it. I have used a scale of font sizes from 75% up to 200% with 25% steps for the tag ranks. Other attributes would be easy enough to fix (font-face, color, etc).

Add the following to the styles-site.css template:

.module.module-tag-cloud .module-list, .entry-tags {
  list-style: none;
}

.taglevel1  {
  display: inline;
  background: none;
  padding: 0;
  font-size: 200%;
}

.taglevel2 {
  display: inline;
  background: none;
  padding: 0;
  font-size: 175%;
}

.taglevel3 {
  display: inline;
  background: none;
  padding: 0;
  font-size: 150%;
}

.taglevel4 {
  display: inline;
  background: none;
  padding: 0;
  font-size: 125%;
}

.taglevel5 {
  display: inline;
  background: none;
  padding: 0;
  font-size: 100%;
}

.taglevel6 {
  display: inline;
  background: none;
  padding: 0;
  font-size: 75%;
}

So how do the graphs look? I ran a few graphs using rrdtool to compare the output.

Monthly Comparisons

While the final calculated 95th percentile is similar in both cases, the internal function gives no visibility on the evolution of the 95th percentile over time, which makes it pretty much useless for trend analysis.

Weekly Comparison

The weekly graph shows a larger discrepancy, due to the fact that cricket-95.pl always calculates on the monthly figures, whereas the internal function graphs based on the sample set to be presented (i.e. only on the week's values)

Conclusions

There's still life in cricket-95.pl. I have developed it beyond the script available on my site and it looks like it's still worth continuing that development. It's just a pain that I can't release any versions newer than the one already on my website due to contractual issues with my employer :(

Appendix: The command-line used

Below is the command-line used to generate the cricket-95 monthly graph

rrdtool graph cr95-month-2hr.png -s 1153436400 -e 1156114799 \
    -S 1800 \
    DEF:in=peer-linx-gw1.rrd:ds0:AVERAGE \
    DEF:out=peer-linx-gw1.rrd:ds1:AVERAGE \
    DEF:pc95=peer-linx-gw1.rrd:ds2:AVERAGE \
    LINE1:in#00ff00:"Input\n" \
    LINE1:out#0000ff:"Output\n" \
    LINE1:pc95#ff0000:"95th Percentile\n" \
    COMMENT:"Cricket 95, 2hr resolution, 1 month"

Below is the command-line used to generate the internal 95th percentile monthly graph

rrdtool graph cr95-month-2hr.png -s 1153436400 -e 1156114799 \
    -S 1800 \
    DEF:in=peer-linx-gw1.rrd:ds0:AVERAGE \
    DEF:out=peer-linx-gw1.rrd:ds1:AVERAGE \
    CEF:max=in,out,MAX \
    VDEF:pc95=max,95,PERCENT \
    LINE1:in#00ff00:"Input\n" \
    LINE1:out#0000ff:"Output\n" \
    LINE1:pc95#ff0000:"95th Percentile\n" \
    COMMENT:"95,PERCENT 2hr resolution, 1 month"