Matt-J.co.uk : Ramblings

I have had a trusty Solaris box at home now for 5-6 years running a few things;
- ZFS for my files, sharing out through SMB for media, iSCSI for playing with Netbooting and VMware shared storage.

- 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?

Here’s something that seems a little interesting, O2 appear to be sending a header of the end users mobile number, to any website visited over their mobile data network.

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

Hi all,

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

Last week I had the missfortune of needing to get some low bandwidth endpoints online for a client, these unmanned locations would have a few peices of technology sat behind an ADSL router with an IPSEC VPN back to a central location,bog standard stuff!

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.

Hot off the press from Jamesbotham.wordpress.com, who kindly found the time to write up our Lync Integration efforts, this article will shows how to integrate Lync 2010 and the Cisco Call Manager Express to offer Enterprise Voice capabilities to your Lync installation.

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.