- Xen (More recently) running on a Solaris Dom0 hosting a number of Centos5 DomU’s for other linux server based stuff.

- Multicast/Bonjour spoofing and apple filesharing making an excellent ‘fake’ timemachine for backing up my Macbook pro onto ZFS (works flawlessly and doesn’t have a single disk prone to failure unlike the time capsules

Over that time, I’ve either in-place upgraded, or overwritten the OS and let the new version of Solaris import the ZFS pool from;

Solaris 10, Solaris SNV_8X (Sun Internal), Solaris SNV_9X (Sun Internal), OpenSolaris (SNV_1XX), Oracle Solaris Express (SNV_151).

And everything was pretty much good :) Until now, now I tried to take the latest update, moving to the newly released Solaris 11.

Lots of things have changed in Solaris 11 compared to the SNV/OpenSolaris/SolarisExpress years (well, i’m not saying there hasn’t been a lot of changes during that time, just none that have negatively affected me, where as these do);

- Support removed for Linux branded Solaris Zones
- Support removed for Solaris 11 to be a Xen Dom0, or indeed be the base of any form of visualization solution apart from Solaris zones and VirtualBox (Guessing to allow Oracle to push it’s visualization product)
- No check in the ‘pkg update’ procedure as to wether the Xen kernel was in use before upgrade.

So, cutting to the POINT OF THE POST, I updated, a new boot environment was created, update successful, rebooted, boot fails!

You could just boot the previous Boot Environment, which works, but this is what you’ll need to do to boot the new BE;

1. Open the grub menu.lst from /rpool/boot/grub/menu.lst
2. Find the last entry in the file (named after the Boot Environment you’re having issues with)
3. Remove the references to Xen, as below;

Before;


title example-solaris-1
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/example-solaris-1
kernel$ /boot/$ISADIR/xen.gz console=vga dom0_mem=2048M dom0_vcpus_pin=false watchdog=false
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive


After;

title example-solaris-1
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/example-solaris-1
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive


We have just removed the Xen kernel and options and instead told grub to boot the ‘normal’ Solaris kernel. It seems pkg update don’t check for this when upgrading.

Now reboot and try the Boot Environment from the grub menu, should load fine and after some information about upgrading the SMF versions, you’ll be ready to login.

The second issue I found after this is that my SMB shares were not available, seemed that the SMB service was stopped due to dependencies, starting the following services magically made my shares come back to life;


svcadm enable idmap
svcadm enable smb/client
svcadm enable smb/server


Verify with ‘share’;

matt@F43-PSRV1:~# share
IPC$ smb - Remote IPC
Matt /F43Datapool/Matt smb -
Public /F43Datapool/Public smb -
c$ /var/smb/cvol smb - Default Share


I hope this helps someone, the last thing I have to work out is whether VirtualBox will provide as stable a solution for my Linux VM’s as Xen (as it seems to be the only option I have now, apart from moving back to Linux and losing ZFS/SFM/Crossbow/Comstar etc which I really don’t want to do).

That said, it really annoys me that Oracle have removed such a simple and powerful combination of Xen Dom0 and ZFS in the base solaris image, it served a perfect need for people who don’t need a full, separate, virtualization product such as testing, home use, small businesses etc. Why remove Dom0 support but keep DomU support! Anyone know?

Header is ‘x-up-calling-line-id’
Other networks don’t feel the need, I wonder what their reasoning is, either way, questionable privacy fail here!

More info here;
http://lew.io/headers.php

And yet, i’m not that annoyed!

Here’s why… and I think in this day and age of everyone worrying about every bit of data, it’s important;

1. I’m called Matt and my blog is at www.matt-j.co.uk. Is it really that hard for a targeted phishing attack to work out an e-mail address in the first place?

2. It’s the register, a website that takes pride in highlighting technical cockups, basterdisations, IT Fo Pah’s and Comical! Yahoo! Related! Exclamation! Mark! Frenzy! Issues! before they’ve even sat down for the morning caffeine…. So no matter how annoyed we are all individually feeling, I’m pretty sure as an organization they’ll be feeling ten times worse for being beaten at their own game.

3. Did I mention it’s the register? I’m finding it quite hard (Maybe a psychologist wants to tell me why) to get annoyed with such an instutution within the industry, somewhere that generally gives you a good morning roundup of crap you need to concern your little head with.

But mainly because (and this is the important bit I was talking about at the beginning, the rest was just to test your stamina and determination!)…
They owned up, instantly, in an e-mail to everyone affected, disclosing figures that are far too un-rounded to be made up!

Yes, I think that’s it… Look at the recent Blackberry incident, it wasn’t that the service was down, it was that no-one from blackberry would give any of the circling vultures a single word for hours, even as speculation grew, nothing, twitter messages a-plenty… nothing! THAT’S the problem.

So ElReg, as much as you’ve amassed a million cocks to put yourself (and my e-mail address) in such a bastardy situation, it’s not going to stop me reading your news in a morning, fair play for making a hard decision.

And everyone else, I don’t claim to know much about business, but if you’re sucking at an all time low when competitors around you selling exactly the same service/product/moon etching laser are doing well, you may want to look at becoming more open and transparent with your customers.

Just my 10p, keep the change!

Matt

Came accross this issue the other day and since i’m currently stuck on a train between London Euston and Manchester, with what could be called a passable excuse of an internet connection, I’ll take a moment to document it, hope it saves someone else some head-scratching.

Issue: If using a Policy-Map based service policy within IOS to filter traffic on an interface and the undelying class-map is edited with any ‘match protocol http <more>‘ statements, the policy-map stops processing traffic, effectivley turning itself off for that interface.

Consider the following, two interfaces;

Vlan 1: 192.168.0.1/24

Loopback 99: 192.168.100.1/24

We the create a simple class-map to match ICMP traffic and use this in a policy-map with a match action of ‘drop’.

We now assign this to the output of the loopback99 interface, with the following command;

conf t
interface loopback 99
service-policy output TEST_POLICY_1
exit
exit

This should now block ICMP traffic (such as an echo/ping) to the interface IP;

We can also see the policy-map status for the interface, showing packets flowing through the assigned service policy and that drops are occuring;

Here is the issue, when we add/change any match criteria in the class-map (TEST_CLASS_1) relating to HTTP, the policy map stops working.

I also I added a ‘match protocol smtp’  before this, but you’ll just have to trust me that the policy-map continued working after that, only the addition of HTTP inspection caused a failure.

And now our traffic fails to pass through the policy-map, allowing ICMP which should be dropped;

The only workaround I have found is to remove the service policy from the interface and then re-add it after a class-map change, this restores correct functionality;

The following further output (too large for a screenshot) shows that while ‘broken’, the traffic was not even hitting the policy-map (as can be seen through traffic counters);

APCI877#sh policy-map interface loopback99
Loopback99

Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop


Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
APCI877#ping 192.168.100.1 source vlan 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
APCI877#ping 192.168.100.1 source vlan 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
APCI877#sh policy-map interface loopback99
Loopback99
Service-policy output: TEST_POLICY_1
Class-map: TEST_CLASS_1 (match-any)
20 packets, 2000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol icmp
20 packets, 2000 bytes
5 minute rate 0 bps
Match: protocol smtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol http host "bob.com"
0 packets, 0 bytes
5 minute rate 0 bps
drop

Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any


I have has a search via google and looked around the cisco bug toolkit, but couldnt see anything exactly matching this behaviour. I will be testing on the latest IOS 15.1 at some point (when i’m infront of a router that has a little more flash/ram).

Any suggestions, comments or blaringly obvious known cisco bugs i’ve missed are welcome on this one!

Matt

Naturally, I’d specified Cisco 877 ISR routers (as anything newer was overkill) allowing a good level of remote management, monitoring and control.

Base configuration was written offline, router is then connected to a BT ADSL2+ socket and an issue I immediatley recognised reared it’s ugly head;

PPPATM: ATM0 0/38 [0], Event = Vaccess Down
%LINK-3-UPDOWN: Interface Virtual-Access2, changed state to down
%DIALER-6-UNBIND: Interface Vi2 unbound from profile Di1
%LINK-3-UPDOWN: Interface ATM0, changed state to down

Errors would repeat every 30 seconds to 5 minutes, nearly two years on, 877′s still don’t support BT’s ADSL2+ connections it seemed!

Expecting a new, working ADSL firmware update in that timeframe, I headed to the cisco.com website and was bitterly dissapointed, even the firmware release ‘patch’ of yesteryear had been removed (which we didn’t have much luck with anyway when it first came out).

I knew we were looking for at least 4.0.0.18 (or 4.0.18 depending on where you see it written), backed up by many sources (just search for ADSL2+ BT Cisco 877).

What’s clear however, is that 4.0.0.18 as talked about all over the place doesn’t seem to be solving anyones problems and after getting hold of a copy by searching google for the what the filename would be based on the 4.0.0.17 download ( http://www.alcatron.net/cisco877/firmware/adsl_alc_20190_4.0.018.bin ) I once again confirmed this, even setting the line type to only ADSL2+ to rule out any negotiation issues still saw consistent drops every minute or so;

conf t
int atm0
dsl operating-mode adsl2+


(At this point it is probably worth mentioning that the 877 will use new firmware as long as it is called ‘adsl_alc_20190.bin’ and is found in the routers flash on startup (if not, the default firmware in the IOS will be used), further details and screensots courtesy of alcatron.net here!)

Eventually, after a lot of firmware testing, I found that cisco have some ‘by request’ only firmware versions which not many people seem to know about.
After testing internal version 4.0.223, I can confirm that my ADSL2+ link suddenly became stable and has continued this way ever since (Now over one week).

I think it’s a little strange that Cisco has kept this one so tightly under wraps.
Anyway, I am not suggesting that this firmware is fit, safe or even sensible to use, but it has resolved my issues here and if you’re reading this and at the very end of your patience with an 877/ADSL2+ combination, you can find the firmware at the link below;

http://downloads.netmetix.net/Cisco/Firmware/adsl_alc_20190_4.0.223.bin

I hope this helps! Let me know if you have sucess with this, would be interested to see how many people are still affected.

The second part of our Lync CUCME /CME integration efforts, once again kindly written up by jamesbotham.wordpress.com (I swear he doesn’t sleep!)

Usual Words of warning..

Be careful if you use these configurations on a live system and do not simply copy and paste this configuration in to a running CME or UC500 system, check your dial-peers and translation rule numbers (“show run” is your friend) otherwise you might overwrite something you later come to regret!

Call Manager Express Inbound Call Configuration

This first key to enterprise voice is to allow the users on Lync to dial our Cisco phone users as well as external numbers on the PSTN. The following example below is from my live running CME router:

dial-peer voice 552 voip
 description **Incoming Call from LYNC**
 b2bua
 session protocol sipv2
 session target ipv4:192.168.100.64:5068
 incoming called-number .%
 voice-class codec 1
 voice-class sip dtmf-relay force rtp-nte
 dtmf-relay rtp-nte
 no vad
!

Nothing clever above, the IP address above is that of your Lync mediation server and the standard mediation server port (5068), keep an eye on the port number and ensure it matches up with your mediation server port if you changed it and do not simply enter 5060 because it is your UC’s SIP port. This port number is the number the UC talks BACK to your Lync server on.

Although the above doesn’t appear to be mandatory as our UC still dialled a number coming out of Lync without this, we found that it was intermittent at best and we could no longer control things such as class of restrictions without it.

Call Manager Express Outbound Call Configuration

The next step is to allow a user to call a user who is on the Lync platform, to do this is a little bit more complicated. To make the experience a little easier on the user (and you can’t easily dial a + on a Cisco phone) we are going to create a translation rule and link this to our dial peer.

By creating this translation rule it will allow a user to dial simply 5xxx and the CME/UC500 router will automatically add the + to the extension as it exits the CME/UC500 system, remember Lync requires e.164 style numbers so this is going to give Lync what it wants.

Be aware single number reach will not work with this configuration, my next blog post will be on how to co-exist with Lync using Cisco Signal Number Reach on the CME/UC platform.

Translation Rules

A translation rule consists of 2 parts, the rule itself and a profile that the rule is linked to, below is the translation rule and translation profile created on our system to make this work. Be aware you need to create the rule first before creating a profile.

The rule below simply adds a + in front of anything dialled that starts with a 5 and is 4 digits long.

voice translation-rule 4000
 rule 1 /\(5...\)/ /+\1/
!

Translation Profile Creation

This profile simply calls the above translation rule.

voice translation-profile LYNC_ADD_PLUS
 translate called 4000
!

Now that we have create the translation profile and translation rule it is time to create a dial peer that will call the Lync server when a user dials 5xxx.

Below is the live running configuration from our CME router, again be wary of the port as it needs to be the port of the mediation server.

dial-peer voice 551 voip
 description ** SIP Trunk to Lync Core **
 translation-profile outgoing LYNC_ADD_PLUS
 destination-pattern 5...
 notify redirect ip2pots
 session protocol sipv2
 session target ipv4:192.168.100.64:5068
 session transport tcp
 dtmf-relay rtp-nte
 codec g711ulaw
 fax rate disable
 fax protocol pass-through g711ulaw
 no vad
!

Once you have done the above is you should now have a fully functional enterprise voice installation, ensure that you enable a user with Enterprise voice.

Enabling a User for Enterprise Voice

An example Lync user configuration is below, enabling Enterprise voice is simple just select the option. It is important to set the Line URI.

In the example below I have configured the “tel:” to be my Lync phone number so in my example below it is 5346 and have also included my Cisco desk phone which is “6346” it is important if you use the extension that you do not add the + to the front of it.

Adding your desk extension improves the Lync experience as Lync will recognise you from your desk phone when you dial in to things such as the conference centre.

Until next time have fun with Lync and Enterprise Voice!!

Lab Configuration
The installation has a 4 digit dial plan, all of our Cisco phones are in the 3… range and our Lync users are in the 5… range.

We currently run a UC560 running CME 8.1 so have no access to E.164 support although 8.5 will have support and is coming to the UC500 soon. This document will allow the configuration without using this support so will probably be updated once I can play with 8.5’s E.164 support.

Lync Configuration

Topology Updates
From topology builder we are going to create a new PSTN gateway, to do this expand your site Media Servers and then select your mediation server and select properties to open the following window.

Select the option “New” to create a PSTN gateway, type in the FQDN if you have an A record setup for your phone system OR type the IP address in. Override the port from the default port to 5060 which is the standard port for SIP and CME’s default configuration, finally ensure TCP is set (TLS is out of scope of this document).

Click OK and ensure you publish your topology to your environment.

Trunk Configuration

Now its time to create your PSTN routing

Create the first of our 2 rules, this rule will remove the +44 (UK dialling prefix, replace with your own if outside of the UK) from the beginning of the number dialled from Lync and replace it with a 0 so that the CME can understand the number we are trying to dial.

Our final translation rules is designed to remove the + sign from the from our extensions as they are being dialled, again this is so that the CME can understand what we are sending it.

Normalisation Rules

Normalisation rules are used to try and form an E.164 number from the digits dialled by an end user, for example if you were to dial 01234 567890 from your Lync client the normalisation rule will turn this in to an E.164 of +441234567890 .

Again we are going to create 2 normalisation rules, to create the first select “New” under the “Associated Normalization Rules”.

This rule is going to allow us to dial a PSTN call through the CME device, we are looking for any number that starts with a 0 and is at least 2 characters long, once we have this we are going to remove the 0 and add +44 to form a valid E.164 number.

Rule number 2 allows us to dial an extension on the CME, this rule finds and number beginning with 3 and is 4 digits long and appends + to it.

Now that your configuration is complete ensure that you select Commit All to upload your dial plans back in to Lync.

Route Configuration

The final piece of configuration on Lync is to create a route from Lync to the CME, below is a working configuration that allows all numbers starting +44 and +3 to be sent to the CME. Ensure that you select the previously configured PSTN gateway as well as a PSTN policy.

Now that the Lync configuration is completed, ensure you go to each section and ensure everything is committed. Once you have committed all of the changes leave your Lync installation, get a cup of coffee and let Lync simmer for around 10 minutes to ensure that everything has replicated around.

In Part 2 we will configure Cisco Call Manager Express to work with the above configuration. Part 2 either HERE or HERE.

… Changing a wordpress theme however, doesn’t take much effort at all! I’ve gone for something a little easier on the eyes (and a little more professional).

Thoughts?

More soon,

Matt

http://www.hpl.hp.com/personal/Vinay_Deolalikar/Papers/pnp_8_11.pdf

“Scott Aaronson, associate professor of computer science at the Massachusetts Institute of Technology, is so sceptical that he pledged in his blog to pay Mr Deolalikar an additional $200,000 (£125,000) if the solution is accepted by Clay.”

http://scottaaronson.com/blog/?p=456

Crazy if this turns out to be true!

Mumblings: http://rjlipton.wordpress.com/2010/08/09/issues-in-the-proof-that-p%E2%89%A0np/

For the uninitiated: http://en.wikipedia.org/wiki/P_versus_NP_problem

The main advantage is they seem to have decoupled memory from the Xeon X86 processors, allowing for extra rackmount modules of RAM without needing extra processors or more servers.

It’s all well and good and i’d like to be able to say, this this the birth of MAN’s (Memory Area Networks) to accompany existing SAN and LAN technology, however; I can’t answer that, as there does not seem to be much technical information available!

For example, is the architechture addressable? can a memory module be connected to multiple server nodes and memory used as needed (like a Dynamic SAN environment can for secondary storage). This would allow the system ideally to scale to a full MAN type scenario, with virtualisation provisioning technologies reserving X amount of memory for new VM’s, could even allow memory sharing between server nodes at memory speeds for clustered applications and failover scenario’s.

-or-

is it, as I expect, some silicon that extends QPI onto some custom IBM external interface, allowing point to point or limited point to multipoint connection to another tray of ram. I get the feeling this is probably more the case.

I cannot confirm from what I have read so far that it’s either of these, but if it was the former I should imagine there would be more of a fuss…

I guess i’ll have to wait a while for a distributed network technology that is still DDR3-Quick even after additional network addressing overheads.

Still, good to see movement from the norm, if for no other reason than to spark technical discussion.

Matt

Further Reading:

http://www-03.ibm.com/press/us/en/pressrelease/29570.wss

http://www.redbooks.ibm.com/abstracts/redp4650.html

ftp://public.dhe.ibm.com/common/ssi/pm/br/n/xsb03013usen/XSB03013USEN.PDF
ftp://public.dhe.ibm.com/common/ssi/pm/rg/n/xso03099usen/XSO03099USEN.PDF