You don't want to read this.

This Sunday, I leave the recently-rainy land of Chicago to go to Cisco Networkers at the Mandalay Bay casino in Las Vegas for a week. While I realize it's wildly improbable, it is nonetheless possible that some of you will be there as well. If so, leave a comment and we'll say hello.

I have to admit that Cisco seems to have put together a pretty impressive list of talks, seminars, labs, and whatever other conference terms are appropriate. Just trying to figure out which ones to attend was quite a task. At any rate, I hope to see some of you there!

I've been fooling around with BGP recently, and the subject of route-maps came up. For those of you playing along at home (and by now, you all should be), route-maps allow one to filter the routing updates that BGP sends. Suppose you are doing something simple like redistributing connected networks into BGP. That works fine, as long as none of them are RFC 1918 space or internal networks that shouldn't be advertised to the outside world. If you decide to hang an internal network off one of your routers (or multi-layer switches) then the default behavior of BGP that's having connected routes redistributed into it would be to advertise those as well. Clearly, this isn't desired behavior.

By using a route-map, you can in effect tell BGP to ignore some networks and not advertise them.

To start, let's get two BGP-speakers up and exchanging connected routes. RouterA has been configured with an IP of 10.0.0.2 and RouterB with 10.0.0.3.

RouterA(config)#router bgp 100
RouterA(config-router)#neighbor 10.0.0.3 remote-as 200

RouterB(config)#router bgp 200
RouterB(config-router)#neighbor 10.0.0.2 remote-as 100

As you can see, RouterA has been placed into AS 100 and RouterB is in AS 200. This is a lab environment so the only reason I used these ASNs is to avoid having to type and re-type the ones allocated in RFC 5398 which are at the higher end of the ASN spectrum.

Anyway, once this has been done, we'll see a log message like this one taken from RouterA:

*May 22 10:40:52.455: %BGP-5-ADJCHANGE: neighbor 10.0.0.3 Up

So the routers are talking BGP to each other but so far no routes are being advertised. To give them something to talk about, we'll add some loopbacks and tell the routers to redistribute those into BGP.

RouterA(config)#int lo0
RouterA(config-if)#ip address 10.100.0.1 255.255.255.255

The RouterA sees loopbacks as directly connected networks, and adds them to the routing table as shown:

RouterA(config-if)#do sh ip ro
C 10.0.0.2/31 is directly connected, GigabitEthernet1/1
C 10.100.0.1/32 is directly connected, Loopback0

The route hasn't yet been redistributed into BGP - we've got to tell it to do that:

RouterA(config)#router bgp 100
RouterA(config-router)#redistribute connected

There are other parameters that can modify the behavior of routes redistributed into BGP, but that simple command will get the job done. Now we wait a few seconds for the updates to be pushed to RouterB and then look at it's routing table:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:00:28

Success! RouterB has learned a route to 10.100.0.1 from RouterA via BGP. Let's add another loopback:

RouterA(config-router)#int lo1
RouterA(config-if)#ip address 10.200.0.1 255.255.255.255

Sure enough, it shows up on RouterB as well:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
B 10.200.0.1/32 [20/0] via 10.0.0.2, 00:00:37
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:06:47

That's fine and dandy assuming we want all the connected networks on RouterA to be pushed to RouterB. If we want to keep 10.200.0.1/32 from being advertised by BGP we can create a route-map to filter it from the list of updates to be sent.

The first thing we have to do is define the route-map:

RouterA(config)#route-map TESTMAP permit 10

Easy enough. 10 is just a sequence number like in regular firewall access-lists and for our purposes doesn't mean anything. The next thing we have to do is tell the router which network we want to permit (the rest will be blocked):

RouterA(config-route-map)#match ip address 1

This tells the router to look at access-list 1 and check the addresses against it before advertising them. Since access-list 1 doesn't yet exist, let's write it:

RouterA(config)#access-list 1 permit 10.100.0.0 0.0.255.255

The only tricky thing, for those of you coming from the world of firewall access-lists is that the netmask is a wildcard mask, not a standard one. Looking at this access-list entry, networks starting with 10.100 are okay to advertise. Everything has been defined with the exception of applying to route-map to BGP's redistribution of connected routes.

RouterA(config)#router bgp 100
RouterA(config-router)#redistribute connected route-map TESTMAP

Just like before, we're telling BGP to redistribute routes for connected networks but we're also telling it to only do so if the routes pass successfully through the TESTMAP route-map. Now that everything is in place, let's look at RouterB again:

RouterB#sh ip ro bgp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.100.0.1/32 [20/0] via 10.0.0.2, 00:19:10

As you can see, the route for 10.200.0.1/32 has been dropped from RouterB's routing table since it was filtered out by the route-map. There are many, many other things that can be done with a route-map, but this is intended to be more of a quick intro than anything resembling a complete guide.

OSPF area types and LSAs seem to be somewhat misunderstood concepts. If you've read this far, you're probably already aware that OSPF makes use of areas to break up the potential administrative nightmare of running an IGP in a network. If you've read THIS far, you're probably also aware that area 0, the backbone area, has a special significance to OSPF. The other area types and the link state advertisements used to toss information around between the routers are where a lot of people get confused.

Standard Areas

A standard area is often described with a phrase like "A standard area is the most basic type of area". Well great - 'standard' in what way? Standard areas can be thought of as being the "equal opportunity employer" of OSPF areas as every router in the area knows about every route. This is just fine if the routers are high-powered enough to store every route and run the SPF calculations without getting bogged down. Type 1 and 2 LSAs are passed between routers to convey information regarding their own interfaces and their neighbors. Internal routes, communicated by type 3 LSAs, and external routes, communicated by type 5 LSAs are sent through all standard areas as well as the backbone area, which is a type of standard area. Type 3 LSAs can be sourced by any OSPF router whereas type 5 LSAs only ever come from autonomous system border routers. Autonomous system border routers are also responsible for generating type 4 LSAs. An area border router that has an interface in that area and an interface in the backbone area will inject the type 4 LSA into the backbone area to ensure the route to the autonomous system border router is known. Type 4 LSAs are only passed internally.

In summary, a standard area can contain LSAs of type 1,2,3,4, and 5.

Stub Areas

If an area can be thought of as a leaf node on a network then a stub area may be appropriate. A stub area can be handy if devices in it are low-powered, or simply have no need to know about every route. A stub area is similar to a standard area, but routers in it are not aware of externally-sourced routes directly. In terms of LSAs, that means that type 5 LSAs are not permitted in a stub area. A type 3 LSA is injected into the area by an area border router to act as a default route, allowing connectivity outside the stub area. The type 3 LSA provides the equivalent of an "All Points East" sign for stub area routers. Type 4 LSAs are not forwarded into a stub area, as the default route is used.

For a router to be in a stub area, the area must be configured as such on all routers involved:

Weasel(config-router)# area 3 stub

In summary, a stub area can contain LSAs of type 1,2, and 3.

Totally Stubby Areas

Totally stubby areas are a Cisco invention designed to take the concept of a stub area one step further. In addition to the lack of type 4 and 5 LSAs, type 3 LSAs, which carry information about internal routes are also prohibited. The concept of an injected default route still applies (the only instance of a type 3 LSA in a stub or totally stubby area) but it also covers internal routes. All traffic leaving the area does so using this default route. While I've never tried this in a lab, I've been told that one can have multiple 'default routes' (in stub, totally stubby, and not-so-stubby areas) and internal metrics will be used to select the least-cost route. If you've tried this, let me know.

To configure an area as a totally stubby area, use the no-summary argument when defining the area:

Vole(config-router)# area 4 stub no-summary

In summary, a totally stubby area can contain LSAs of type 1 and 2 as well as a type 3 LSA for the default route.

Not-so-stubby Areas

Yet another Cisco-concocted area type, the NSSA is a variant of the stub area type but is allowed to contain an autonomous system border router. Since type 5 LSAs are not permitted in stub areas of any type, a type 7 LSA is used. For the record, there is a type 6 LSA that is used by Multicast OSPF. MOSPF is an extension of OSPF designed to support (surprise!) multicast. At any rate, a type 7 LSA is essentially a type 5 LSA with a fake beard and glasses on. It performs the same function as a type 5, but is permitted through NSSAs. A hard-learned lesson for me was that by default an NSSA does NOT have a default route injected into it by an area border router. To have one (yes, please) the default-information-originate argument must be used:

Marmoset(config-router)# area 5 nssa default-information-originate

This comes in handy if one wishes to route traffic out of an NSSA.

If totally stubby area functionality is desired, all area border routers must be configured appropriately:

Marmoset(config-router)# area 5 nssa no-summary

Note that if an NSSA is configured to behave like a totally stubby area, a default route IS injected by the area border routers so the default-information-originate parameter is not necessary.

In summary, a not-so-stubby area can contain LSAs of type 1,2,7 and if configured for it, a type 3 for a default route.

Bonus Fact

Type 8 LSAs are very rarely used, but can carry BGP information over OSPF. I haven't the faintest idea how to use them, so don't ask.

LSA types 9 - 11 are called 'opaque LSAs' and are reserved for future growth. I plan to make use of them in my proposed "Kinda-stubby-but-only-if-you-squint-right" area.

While I'm pretty sure all of this is correct, it's possible that I either missed something or made a type somewhere. If you spot an error, please let me know so I can correct it.

Like most of you out there, I think about OSPFv3 and IPv6 regularly. Looking up 'regularly' in the Philip-English Dictionary we see it defined as "the day before yesterday while I was on my way home from work". Specifically, I was thinking "Huh - I don't know much about OSPFv3, and even less about IPv6".

IPv6 as I'm sure you're aware, was first proposed several years ago to put some of our out-of-work bits back to work. We've got bits everywhere with nothing to do, and here we are using a measly 32 of them in an IPv4 address. Cranking that number up to 128-bits allows us to take some of these bits off the street and make the internet more confusing to boot. It's really win-win.

With these two thoughts in mind, I decided to set up a little IPv6/OSPFv3 lab. Grabbing a spare 6504 and a couple of 4948s I set to work.

Lesson The First: any IOS version that has "ipbase" in it's name will not work. You'll be able to put an IPv6 address on a routed interface, but the command to enable IPv6 routing device-wide is missing. Go for "ipservices".

ipv6 unicast-routing is the universal command to enable (surprise!) IPv6 unicast routing. ipv6 cef could also be enable if you want to use uRPF (Unicast Reverse Path Forwarding).

Putting an IPv6 address on an interface is as straight-forward as it is in IPv4:

IPv6Lab1(config-if)#no switchport
IPv6Lab1(config-if)#no ip address
IPv6Lab1(config-if)#ipv6 address 2001:410:0:5::1/64
IPv6Lab1(config-if)#ipv6 ospf 1 area 0

Notice that the last command explicitly places the interface into OSPF area 0. Rather than say "All interfaces in network x.x.x.x/y go into area z" it's on an interface by interface basis. Personally, I think this makes it much clearer, but if there's any confusion there's always the fall-back command:

IPv6Lab1#sh ipv ospf int b
Interface PID Area Intf ID Cost State Nbrs F/C
Gi1/47 1 0 58 1 DR 1/1
Gi1/48 1 0 56 1 BDR 1/1

The bulk of the commands related to IPv6 differ only from their IPv4 counterparts in that one uses "ipv6" instead of "ip". A major gripe I have with Cisco (other than those currently displayed at dearcisco.com) is that sh ip int b shows nothing related to IPv6. Not even an indicator that the interface HAS an IPv6 address. sh ipv int b shows this information but in a much more vertical format rendering it easy to scroll off the screen. I recommend using sh ipv int b | e do|una as it filters out all the 'down' or 'unassigned' interfaces.

Getting back to configuring IPv6 addresses, the ipv6 address <blah> command can take an additional parameter of eui-64. This seems to work the MAC address into the IPv6 address which can be a bit confusing; suddenly there are a bunch of hex characters that weren't typed in. Anyway, on with the show.

OSPFv3 has some other little quirks that are handy to know. In previous versions, there was a hierarchy that OSPF would go through to select the router ID used by the device. First, it would check for a hard-set router ID. In the absence of a hard-set RID, the highest IP address on the loopbacks would be used. If no loopbacks are set, the highest IP anywhere on the device is selected. Obviously it doesn't make sense to have an OSPF process running if there isn't a layer 3 configuration on the device. With IPv6 and OSPFv3 one might think that the same logic would apply. It does. Identically. IPv6 addresses are not used for RIDs (possibly for sanity reasons) in OSPFv3. If no hard-set RID or IPv4 address is configured anywhere on the device OSPF will simply refuse to start. The day will come (if it hasn't already) when someone new to a configuration will remove the "pointless" IPv4 loopback on a device. It won't be a problem at first, but when either the chassis or the OSPF process reloads OSPF won't come back up. Brace for impact.

The moral of the story is the the output of sh ipv ospf nei will look shockingly similar to that of IPv4 and earlier versions of OSPF:

IPv6Lab1#sh ipv o n

Neighbor ID Pri State Dead Time Interface ID Interface
10.0.0.4 1 FULL/BDR 00:00:36 7 GigabitEthernet1/47
10.0.0.3 1 FULL/DR 00:00:35 54 GigabitEthernet1/48

While I won't bother repeating the commands of adding an IP address to an interface and adding an interface to an OSPF area, below are the end results of my fiddling. The topology is three devices arranged in a triangle, all IPed interfaces in area 0.

IPv6Lab1#sh ipv route
IPv6 Routing Table - Default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
C 2001:410:0:1::/64 [0/0]
via GigabitEthernet1/48, directly connected
L 2001:410:0:1::1/128 [0/0]
via GigabitEthernet1/48, receive
LC 2001:410:0:2::2/128 [0/0]
via Loopback0, receive
OE1 2001:410:0:3::2/128 [110/21]
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
C 2001:410:0:5::/64 [0/0]
via GigabitEthernet1/47, directly connected
L 2001:410:0:5::1/128 [0/0]
via GigabitEthernet1/47, receive
O 2001:410:0:6::/64 [110/2]
via FE80::226:CBFF:FE30:8980, GigabitEthernet1/47
via FE80::8A43:E1FF:FE08:7C3F, GigabitEthernet1/48
L FF00::/8 [0/0]
via Null0, receive

As mentioned in other attempts at tutorials, I am by no means an expert. According to Cisco, I'm merely an "associate". No guarantees are made as to the accuracy of this information. I may be wrong - in fact, I probably am. Consult a physician before changing your dose.

This past weekend, I purchased the latest installment of the Command & Conquer franchise, "Tiberian Twilight". As a long-time fan of this series, I looked forward to playing what is said to be the final installment.

It seems that Electronic Arts has decided that it no longer cares about producing a quality product and instead has taken the George Lucas strategy of "who cares if they like it, I'll still make money" to heart. Several facets of basic gameplay have changed from previous incarnations, not in the slightest for the better.

The first major difference in purely a UI change, but the time-vetted sidebar control has been replaced by one at the bottom of the screen. Many times while playing this game I've started to move the mouse to the side, but that's not a huge deal.

Tiberium harvesting, one of the critical tasks of earlier version has been replaced by a system involving "command points". Tiberium is still present in the game, but instead of fields to be harvested they're now single crystals that must be returned to player-controlled land to get points that can be spent on upgrades. Every unit, rather than having a monetary cost, costs a certain number of command points, almost always in multiples of three. This would be tolerable if one was given a number of command points that was divisible by three. Instead, one is typically left with a few worthless points that can't be used for anything. The command points limit equates to a population limit which is a familiar concept to gamers. However, since any unit of real value costs at least six points, one maxes out the population with 15 or so units - the days of fielding a massive army are over.

Base design used to be a major strategic decision, as one needed to place critical buildings in protected areas so they wouldn't be vulnerable to engineers or combat units. No more. Bases have been replaced by the "crawler", a single unit that packs and unpacks like the MCV in days gone by. It produces infantry, vehicles, planes, and base defenses (based on your class - more on that later) and can be moved at will. Part of the excitement in previous games was losing buildings and having to compensate while you rebuilt, and the fun of taking out an enemy's power plants, shutting down their base defenses. Your crawler can be destroyed, but you can immediately drop another one from space and you're back in business. Crippling attacks on an enemy's infrastructure simply can't be done.

Crawlers fall into one of three classes, offense, defense, and support. Clearly this game was designed to be played exclusively in the multi-player arena. The offensive class fields vehicles like tanks and walkers. Defense allows one to build base defenses like turrets and SAM sites, but limits your ground units to infantry and a vehicles or two. Support class weapons are predominantly aircraft. Why I can't have both tanks and planes is beyond me.

The graphics are a throw-back to the original "Warcraft" where it was impossible to tell different infantry types apart. While it can be done here, it seems that the graphics budget was instead blown on the neighborhood community theater from whence they apparently sourced their actors. Grainy and pixelated, they simply serve to detract from the already awful game play.

I mentioned the acting a moment ago, but just in case theirs any confusion I'll talk about it a bit more. I've seen better acting from extras in Godzilla movies, but given the quality of the plot I imagine they would have had trouble getting someone as talented as the people in the Doritos "Friendchip" commercials. For example, the apparently awesomely-skilled sniper in campaign mode is an aging black female who could have been edged out of the role by a bottle of shampoo. The person who in the role of the player's wife is a 30-something white female capable of making Keanu Reeves look like the genius thespian of our time. Her delivery of "What's the sound?" made me consider euthanizing my speakers out of pity. The plot, which I stopped paying attention to three minutes into the game, apparently involved something about the Scrin (see C&C III) who apparently decided Earth wasn't worth invading after all but graciously left some of their technology behind. "Dick and Jane At The Seashore" is a taut thriller in comparison.

What I miss the most though, is the the way skirmish mode used to work. One could choose a map, a number of computer-controlled opponents and their skill, and play any number of different combinations of games. The gameplay now is directed solely at multi-player (in fact, you have to be on-line to even play it). The AI is dreadful and the only game mode is a variant of "king of the hill" wherein one must control "tiberium control nodes" to gain victory points. When one amasses 2500 points (which can't be changed) one (surprise!) wins. Every games plays out identically - there's an early land-grab and then it's just about becoming a turtle and waiting for the enemy to come to you (which may or may not happen).

All told, this game is simply awful. Were I on the project team, I would be truly ashamed to have my name associated with this piece of software. Terrible graphics, awful story, abysmal acting, dreadfully predictable AI, and atrocious gameplay make this one sorry excuse for a Command & Conquer product. I have never played a more poorly-written RTS game in my life.

A final thought. This game strikes me almost as an attempt to recapture some aspect of gaming in the days of yore. I'm not sure what they were trying to recapture, but I sincerely hope that whatever it is is protected by the Geneva Convention.

As part of my periodic process of looking through my server's logs and seeing who I should block (UFW is a fantastic iptables wrapper, incidentally), I ran across an IP that apparently belongs to Google Reader. I did some digging around on the Google Reader site, and it seems that this particular blog of mine has somehow acquired 23 subscribers. This is not to say that this blog is hosted on a server I own - this blog is generously hosted by DLuke. I haven't the faintest idea who these subscribers are, but hell, I'll take 'em!

Speaking of Google Reader, there's apparently a Facebook application that claims to allow you to use Google Reader form your Facebook account. As a former English teacher of mine recently discovered, using this application will summarily get your IP address blacklisted by Google. So you might want to stay away from that; or don't - I can't make all your decisions for you.

Don't you want to know what kind of TV it was? How about what floor it was on? This is important information to track!

Periodically while studying some aspect or other of linguistics, I come across factoids regarding the etymology of a word or phrase. While they're not usually of any great significance, I think they're fascinating.

The word 'cattle' comes from the Old French chattels referring to all things a person owns.

'Spree' comes from a Scottish word meaning "cattle raid".

'Eulogy' originated in Ancient Greek. The original meaning was 'good word'.

The Gaelic word for 'war cry' was 'slogan'.

During a British military operation in India, the city of Sind was under siege. A message was sent from headquarters to the general leading the attack asking how the battle was going. His response was a single Latin word; Peccavi. The translation is "I have sinned".

If you've got any you'd like to share, be all means do so.

It's well and widely known that languages evolve over time. Sometimes they change if words fall into disuse ('haberdasher' in English), a word takes on a new meaning (historically, the Arabic word for 'house' meant 'tent'), proximity to another culture (the British Isles being repeatedly overrun helped produce English as we know it today) or sometimes for no clear reason at all (the so-called Great Vowel Shift responsible for the English 'burning' versus the German 'brennend').

Periodically though, pronunciations will change simply because they're easier to say. Euphonic assimilation is responsible for 'goodog' as opposed to 'good dog' in English, but sometimes the change will actually alter a letter. Eventually it may be accepted as the common spelling. Typically though it seems to be confined to 'classes' of letters. A 't' may evolve into a 'd' for example, as they are both 'dental' letters, produced through a similar process involving the speech organs.

While listening to the song 'Vergissmeinnicht' by Eisbrecher recently, it dawned on me that 'vergissmeinnicht' meant 'forget-me-not' ('eisbrecher' incidentally, means 'ice breaker'). It's a fairly obvious conclusion even if one (such as myself) doesn't speak German.

F and V are both labiodental fricative (I've also seen them referred to as 'plosive') letters. The difference between the two of them being that V is voiced and F is not. It's easy to see how over time one letter could gradually be replaced by the other. The major limiting factor as I see it in English is that there are English words that already are 'place holders', prohibiting some changes from taking place. 'Very' would have a hard time becoming 'fery' as 'fairy' and 'ferry' already exist. Not that it's impossible, but it would seem to me to be easier to transition if there were no sound collection already existing.

Language is a very time-sensitive subject. Some researchers think that spoken language evolved out of a need to warn others in the pack about impending dangers. Clearly there's an advantage to being able to warn others quickly. As such, it makes sense that spoken language would, like electrons in an atom, seek a 'low-energy' state where the least amount of energy was exerted to communicate the message.

This implies perhaps that some transliterations are more likely to happen than others. A Z is more likely to evolve into an S than vice versa as an S is easier to say. Hence the name 'euphonic'.

Anyway, it seems that an F is a more 'natural' letter than a V as a voiced letter should always require more effort than it's unvoiced alternative. Since the English equivalent of vergissmeinnicht starts with an F, it seems to suggest that perhaps the original shared root started with an F which was the sounds maintained by English. The questions then arises as to why a language would intentionally adopt a sound that requires more effort? The alternative is that the original root contained a V sound and while English has settled on an F German maintains the original sound.

The second syllable consonant, G, is shared by both languages.

The puzzle for me is the third syllable. English uses a palatal T sound whereas German has an unvoiced sibilant (or palatoalveolar fricative). The sister letter of T is D and that of S, Z. Were German to use a D here or English a Z the resemblance would be clear but I'm at a loss to explain why we're left with the two sounds we have. It's possible I suppose that S evolved out of a now lost palatal sound similar to an open 'sh' sound.

Looking at the two sounds we have to work with, the S seems to me to be the winner in terms of ease of pronunciation. Could it be that in the ages before Germanic split into upper and lower Germanic the root was *FGS (for those of you playing along at home, the * indicates a supposition or uncertainty)? I'd love to know. If an email was sent out detailing this at some point, I didn't get it so please forward it to me.

As for the rest of the word, 'mein' is a fairly commonly known German word, as is 'nicht'. Being the semi-agglutinative language German is, they all get slammed together. I guess we English speakers prefer hyphens.

Since I spent so much time on it, here's a chunk of the song that spawned this whole diatribe:

Verzeih mir - bleib bei mir
und ich sagte noch Vergissmeinnicht
Ich schenk dir zum Abschied
ein letztes Licht
Vergissmeinnicht

Translation:
Forgive me - stay with me
and I still said forget-me-not
I'll give you as a goodbye
one last light
Forget-me-not

For those of you playing along at home who also have to have an ASA running 8.0 or 8.1 code, pay attention. The rest of you, go about your business. Move along, nothing to see here...

Cisco recently announced that a flaw exists in ASA 8.0 and 8.1 code that can force the device to reload itself if a specially-formed HTTP packet passes through it if SSL VPN is being used. There are a couple of other conditions, but from what I've read they're all pretty non-standard configurations.

The moral of the story - keep your code up to date.

There's also a paper being released at Black Hat Europe next week that will supposedly reveal a fundamental flaw in BGP and MPLS of a comparable seriousness to Kaminsky's DNS exploit of several months ago. So all those of you who run BGP (yeah yeah I know, no one who runs BGP is going to be reading the blog of little old me), heads up.