Archive for the ‘Cisco’ Category.

Modem to Cisco 2811 Console port

I’m having a tough time getting this to work, so expect a few revisions to this.

I’m confused as to why this is so difficult. Below is my post to the Cisco NetPro forum. I’m hoping they’ll be able to help eventually, but I thought I’d include it here for the record. I know a few Cisco schmartypantsh people whom might read this. ;)

Hi all,

I am wondering if someone may be able to point out where I’m going wrong.

I want to be able to see/user the boot cycle/ROMMON mode of a 2811 router, remotely.

As I understand it, the only way to achieve this is with an analogue modem connected to the Console port.

I’m doing the testing here with a Cisco 2651 as it’s the only router I have available to me locally, though as most of the configuration is modem-side, I feel that it shouldn’t make much of a difference..

I’m using a Hayes External Serial modem, connected to the Console port with a Cisco-provided 25pin D -> RJ-45 roll-over.

However, after using this guide, I’ve not had any success. The basic principles appear the same as with a router, but when I dial in, the modems handshake and connect but HyperTerminal displays nothing. There is no output at all UNLESS I enable the ‘post-dial window’, and then I can control the console. My issue is that this is not a native console – there’s no xmodem support and I wouldn’t have a clue how to duplicate this work-around in another client (minicom or screen, for example.)

I’ve noticed that the S37=9 (listed in the guide as the setting for 9600kbps) is not a value that is saved in the current profile. Perhaps the Hayes set has been updated since the article was written. Does anyone know a better way to set this? I have found a way of forcing V.32, which is 9600, but .. is it correct?

Here is the current profile stored on the modem:

ACTIVE PROFILE:
B1 E1 L1 M1 N0 Q0 T V1 W2 X4 Y0 &C1 &D0 &G0 &J0 &K0 &Q5 &R1 &S0 &T5 &X0 &Y0
S00:001 S01:000 S02:043 S03:013 S04:010 S05:008 S06:002 S07:050 S08:002 S09:006
S10:014 S11:085 S12:050 S18:000 S25:005 S26:001 S36:007 S38:020 S46:138 S48:007
S95:000

(Note that I set ATE0 and ATQ1 when testing, but these were flipped for the purpose of viewing the config ;) )

Here is the config from the router:

line con 0
exec-timeout 5 0
logging synchronous

I *think* this is a problem with the speed not detecting the speed of the console properly, but I’m not experienced enough with modems at this level. I’ve even consulted my CCNP2 book, only to find that it concentrated more upon the Aux port.

I can get modem -> Aux working, but that’s just not flexible enough (despite its advantages.)

If anyone can help, I’d be extremely grateful. If you require any more information, I’ll be happy to provide it! :)

Thanks,

Tom

If anyone has any insight into why HyperTerminal is behaving in such a fashion, I’d love to know. :)

The Cisco IOS copy command

Update: On my last trip to the hosting facility where this router’s stored, I took the opportunity to test the theory of a non-Cisco CF card knobbling the successful restart of a router. I was sure I’d checked already, but I wanted to be sure.

Thankfully, it restarted without a hitch. So I guess there’s zero cause for alarm. :)

I know I’ve not written on this log in a long while; I’ve been so busy following the departure of my predecessor, that it’s left me with little time (or will) to write about technology. More to come on this though. I’m still meant to be using this blog as a placement log, so I should really document what I’m doing.

Anyhow, as it happens I’m sat with very little to do at the minute, so I thought I’d write about something that really got me annoyed a week or so ago.

OK, so anyone who’s had the pleasure of setting up a VoIP system based around Cisco CME will know that the flash: directory rapidly fills up with a tonne of files. Config files, language files, firmware files… Basically; a lot of individual little files inhabit your CF card.

Now, on a recent trip to our co-location facility of choice, I wanted to take the opportunity to upgrade the flash card in our voice router. This is a 2811, with the basic 64MB CF card pre-installed, and recently it’s become a pain in the arse working with newer phones (7941′s, in my case) because the firmware files were just taking up too much room. Not to mention you’re only left with ~14MB free space after uploading the IOS image.

So I purchased a 256MB CF card, for about £8 inc. delivery (a mere shadow of the £202-400+ that Cisco wanted for a god-damn CF card of the same size!) and grabbed a standard-affair USB flash drive to use as temporary storage whilst shifting files from one card to the other.

Now, when you’re deleting files en masse from a Cisco flash: directory, it’s possible to use wildcards in order to catch multiple, similarly-named files and delete them all in turn. Which is quite useful if you’re working with 20 config files that all begin with ‘SEPSomethingOrOther’. So because of this included [20th Century] functionality, one would also assume that Cisco would have also included the use of wildcards into the copy command…

Have they bollocks!


RouterX# copy flash:its\SEP* usbflash0:
LOL * IS NOT A VALID FILENAME CHARACTER


RouterX# copy flash:its usbflash0:
LOL CAN'T COPY FOLDERS!

So not only is it retarded enough to not recognise ‘*’ as ‘please copy anything that begins with the preceeding phrase’, it’s also completely inable to copy an entire directory! I cannot believe that Cisco are up to release 12.4(15) and haven’t included some way of copying files en-masse.

It took me bloody ages to copy each of the 62 files from flash: to usbflash0:, swap the CF cards over, and then copy 62 files back to the new CF card. What a horrid waste of time, Cisco.

My good friends at Cisco: if you’re reading this, for the sake of all that’s useful, bloody-well sort it out!

Bad SIP transfers in CME 4.0/4.1/4.2

Whilst I’ve been messing about with registering a Grandstream GXP2000 to our CME 4.2 server’s SIP service, I’ve found quite an annoying problem.

The phone registers fine and can make external calls via the SIP trunk absolutely fine. The phone will also accept transfers of internal calls (ephones), but if I attempt to transfer an external call form an ephone, to the Granstream – the external call is cut-off. I’ve isolated the ‘debug ccsip messages’ output which describes what is happening, but I’m by no means an expert in debugging SIP output.

Aug 14 09:16:49.807: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REFER sip:07xxxxxxxxx@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-SIPGateway/IOS-12.x
Timestamp: 1187083009
Refer-To: sip:2007@cme-router?Replaces=E72682C6-497D11DC-90D890FC-79F613F8%40cme-router
%3Bto-tag%3Ddb0457357be0d469%3Bfrom-tag%3D2CD77068-25C3
Referred-By:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633;received=cme-router
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
NOTIFY sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Contact:
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: refer;id=102
Subscription-state: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 49


SIP/2.0 481 Call leg/transaction does not exist


Aug 14 09:16:49.815: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Date: Tue, 14 Aug 2007 09:16:49 GMT
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
Content-Length: 0


Aug 14 09:16:49.843: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK136ae0fa;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 105 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0

My voice service voip config is as below:

voice service voip
allow-connections sip to sip
no supplementary-service sip moved-temporarily
sip
registrar server expires max 240 min 60
no call service stop

And the Grandstream phone config is:

voice register dn 1
number 2007
allow watch
refer target dial-peer
mwi
!
voice register pool 1
id mac 000B.820D.0536
number 1 dn 1
template 1
dtmf-relay rtp-nte
voice-class codec 1
description Grandstream

Where ‘cme-router’ is the router on which CME 4.2 is installed and running, and ‘asterisk-sip-gateway’ is our SIP gateway (which the CME 4.2 SIP-UA connects to) that handles more advanced call routing features.

If anyone has any ideas – I’d appreciate the help! It’s not a massive problem, but I’m keen to see this one through.

Testing translation rules

When you’re testing translation rules on a CME setup, you need to be very careful. An example of the test command:

test translation-rule 1 01234555321

Don’t assume that just because there is no output from the test, that nothing has been matched. If there are no matches across any of your rules, you will see:

01234555321 Didn't match with any of rules

If there’s no output, then you have a partial match. If you issue ‘debug voice translation’, and watch carefully, you will see output such as this:

Router(cfg-translation-rule)#do test voice translation-rule 1 0123
Router(cfg-translation-rule)#
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=1
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=2
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=3
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=4
//-1/xxxxxxxxxxxx/RXRULE/regxrule_rule_match: partial match found, partial_match 4

There is a problem with this: if your translation rules are mistakenly waiting for any number (as mine was this morning; I’d left a .* on the beginning of the expression!), then your calling will exhibit some odd behaviour.

For instance, when dialling extensions from one ephone to another (simply across CME) your call will be subject to the ‘timeout interdigit’ value (as set in telephony-service). Why? Well, if your translation rules pick up a partial match they wait for a predefined length of time to see if you dial any other digits. The time waited is predefined by the interdigit timeout!

Even if the number matches the correct dial-peer (eg. 20001, 20002) and eventually dials correctly, you will still be subjected to the interdigit timeout, despite the lack of any ‘T’ in your destination-patterns. This is purely because the translation rules are waiting on your dial pattern.

Just thought I’d mention it. Really confused me this morning – many thanks to Tele for helping out!

Cisco IOS 12.4(15)T – A warning for all

A short while ago I discussed the merits of Cisco’s CallManager Express 4.0 software, over their previous 3.3 release which I had been using. It really was a big improvement, but alas there was still some functionality missing that I really required (namely the ‘blf-speed-dial’ command.)

So the hunt began, and seemingly not long before we’d started looking, Cisco had released IOS version 12.4(15)T, which indeed comes with CME 4.1 bundled in the appropriate voice-related featuresets. I chose this release, as the only alternative was an earlier X release. And I’m still quite un-sure of X releases, as it happens.

Now for the severe warning:

Do NOT attempt to register an Snom 360 SIP phone to the SIP registar with this release. We’ve tested a few non-Cisco SIP phones so far, all with varying degrees of success (the Grandstream GXP2000 worked well, though it’s far from usuable*), but the Snom actually caused the router to crash and reboot each time it attempted to register.

Strange but true – a SIP phone registering caused the router (a 2811) to bomb-out and restart at least six times before I realised what was going on. I guess there’s one reason why the more experienced Cisco geeks shy well away from T-train releases…

To make matters worse, I’ve found another strange, yet seemingly harmless bug with this new image. Whenever a call is made, and it doesn’t matter where it’s orginated or destined for; as soon as the call is answered the CLID is suffixed with seemingly random crap. Due to the fact that most of it is garbage, with the rest resembling bits of caller IDs from previous calls, I’d hazard a guess that this is some sort of memory over/underflow issue (but I’m no experienced programmer, so feel free to correct me.)

I’m also not sure whether it’s the IOS release, or CME 4.1 which is causing the problem. I’ve not had the 12.4(11)XJ3 release to test it with, and I’m more-likely to push fowards instead of backwards as there’s since been a newer IOS released with CME 4.2 and I’m hoping it will solve the problem. The only problem is, it’s another X release. :(

What I do know though, is that changing the 7960 firmware load makes no difference what-so-ever. I’ve tested 8.0(5.0) (which happens to be the recommended version for use with CME 4.1), 8.0(6.0) and even 8.0(4.0) with no change in behaviour. The only thing I can attest to is that the Grandstream SIP phone I’m using for testing purposes doesn’t exhibit the same problem. That’s one yay for SIP, at least. :D

If anyone out there is experiencing the same problem, then please let me know any possible solutions that I could test! :)

*The Grandstream can currently dial extensions registered to both CME, and our Asterisk gateway but as for calling externally – I merely receive a 403 error. Maybe I need to keep playing with it, but I don’t think Cisco’s implementation of SIP still particularly favourable…

CallManager Express and “shared lines”

I haven’t updated for a while, due to being really fed-up with going in circles on this new phone system, so please bare with me. What follows is some hard-learned experience (and there’s certainly more of that to come) that I’d like to share with the world, as well as document for the future of course.

You could be mistaken for thinking that when sharing DNs between two SCCP ephones with Cisco’s CallManager Express software, that once a single call to that DN is answered, any other calls to the same number would still ring on an idle phone using that DN – much like a parallel hunt-group (which, for SCCP phones, is definitely missing from CME.)

But no, this just doesn’t happen. As soon as a call to a particular DN is answered on one ephone, any other ephones sharing that DN will not receive incoming calls – the original ephone locks the DN so that it is the only recipient of further calls to that DN, that is until the DN is not in use any more and only then does the ephone release control of the extension.

You could also be mistaken for thinking that specifying ‘dual line’ on the end of a DN would solve this, but it doesn’t – the second incoming call will only display as a call waiting on the ephone currently using the DN. It’s actually quite frustrating to setup a ‘simple’ parallel ring group with the required (read: correct) functionality for our primary office extension.

So I’ve concocted a dirty little hack to deliver the required functionality, which is actually based on this config snippet, andcommented it below for the benefit of anyone else experiencing the same headache.

First, you need to setup your ephone-dns:

!
ephone-dn  1  dual-line
 number 1000
 no huntstop
 ephone-dn-template 1
!
!
ephone-dn  2  dual-line
 number 1000
 preference 1
 huntstop channel
 no huntstop
 ephone-dn-template 1
!

The are some important things to note here are; firstly these are two separate DNs, but they are both set to ring with the same extension.

The ‘preference 1′ value in ephone-dn 2 forces the preference of that DN to a value lower than ephone-dn 1 (which has the default preference of 0 – lower value = higher preference) – this makes sure that hunting for number 1000 will always look towards ephone-dn 1 first.

The ‘huntstop channel’ command on ephone-dn 1 stops CME from placing a call in waiting to the first extension, when it’s already in use. If this isn’t configured, CME will see that there is a free line on the DN and simply queue up the call there, instead of pushing it to the next-preferred DN. You could just not use dual-line DNs to save yourself the trouble, but I didn’t want to limit our functionality in any way and has proven to be just as good.

Note that I have omitted ‘huntstop channel’ on our second DN, as it is unlikely that we will receive three consecutive incoming calls, but in that possible scenario, it is acceptable for the call to queue up as a call-waiting on the second DN. This is purely to avoid giving any of our customers busy signals! Of course, you should have configured ‘call-forward noan’ on these DNs so that un-answered calls are forwarded to voicemail. ;)

Finally, the ‘no huntstop’ command prevents CME’s extension hunt from halting at the first DN, should the DN be busy with another call. If this is not configured, CME will examine the first DN, see that it is busy, and simply send a busy tone back to the caller – not at all useful. Using no huntstop will mean that if the preferred DN is busy, other DNs with the same extension will also be considered during the hunt.

When setting up your ephone configuration, the choice is yours. However, since all our staff are using Cisco 7960 phones, and have a number of blf-speed-dial lines as well as requiring the use of a DDI extension and 2 or more shared extensions – overlay buttons were chosen for efficiency.

!
ephone  1
 device-security-mode none
 description Tom's Phone
 mac-address 0123.4567.89AB
 ephone-template 1
 blf-speed-dial 2 1002 label "Extension 1002"
 blf-speed-dial 3 1003 label "Extension 1003"
 blf-speed-dial 4 1004 label "Extension 1004"
 blf-speed-dial 5 1005 label "Extension 1005"
 type 7960
 button  1o1001,1,2
!

So in this example, we have an ‘o’ type button defined, with 1001 (a DDI extension) as the primary line and our ring group extensions hiding behind it. If you were to press the corresponding button for this line, on your phone, CME would pick the first available line that isn’t in use (which should be your primary DDI extension… Unless you let someone share it! ;) )

Note: ‘Busy Line Field’ speed dials aren’t available on anything prior to CME 4.1, but they sure are bloody useful.

Anyway, hopefully that’s helpful – I’d be very happy to know if it’s helped, so all comments are welcome! :)

< CME 4.1

Well, I think I might have worked out why we’re having transfer problems from external numbers, to a CME SIP phone via a normal CME SCCP phone on full-consult…

Only CME 4.1 supports the command set ‘voice register dialplan‘ – CME 4.0(2) doesn’t have such a command.

And there’s only one IOS that comes with CME 4.1, available for a 2811. And it’s an XJ3 release.. Is that more unstable than a T train? Probably, but I think I’m going to have to test it anyway!

Thankfully our second 2811 isn’t being used for anything other than a few SCCP phones at the minute. :)

That Cisco way

So in the last few days I’ve been playing around with a new Cisco 2811 and CallManager Express 4.0. One thing that’s bugged me hurrendously, ever since I began working with CME, is the generation of config files. When I first started my job, the phones were running from an Asterisk PBX which also hosted the TFTP server (naturally), and when we first began experimenting with CME 3.3 the TFTP server was kept in place upon Asterisk for simplicity and testing speed. However, we’re hoping to move all the phones to CME now, so the TFTP server had to be there too.

The problem is, according to any documentation that you read about creating individual configuration files for SCCP (or SIP) phones on CME, all you’ll be told is:

RouterX#(telephony-service) create cnf-files

And that’s it. But if you dig a little deeper, you’ll find that storing the cnf-files in the system: directory is the default (unbelivably stupid, as I’d imagine it just rapes your router’s RAM). So to remedy this:


RouterX#(telephony-service) cnf-files location [ flash: | tftp: | etc. ]
RouterX#(telephony-service) cnf-files perphone
RouterX#(telephony-service) create cnf-files

And then you should have something that works. But does it? Well, upon running create cnf-files, if you’ve changed it, the localised tone file for your network locale should have been generated and placed into flash, but there won’t be configuration files for each registered phone until you enter another command:


RouterX#(ephone) type [ 7960 | 7970 | etc. ]

And that must be applied for each and every ephone (note: CME allows you can use an ephone-template to achieve the same effect across multiple ephones) before an individual configuration file is generated. It makes sense now that I write this, as phones would inevitably require different configurations, but you try finding any relevence to this in Cisco’s documentation. I wonder how many voice engineers blindly set this value as good practice, not realising that it’s required for perphone configuration?

Meh, it keeps me occupied! :)

All said and done however, I have to say there is a lot more SIP functionality in this newer release, compared to the older 3.3 release I was originally using. Notably the support for SIP MWI is there (though I’m not sure if that might’ve not worked in 3.3, we might’ve just been doing something wrong) and it works a treat. Come to think of it, there’s been a huge improvement in SIP support across the board. This is more than likely because Cisco is moving to phones which support SIP natively (the SIP firmware for 7960‘s is very lacklustre if you wish to have any advanced features from your phones) and that is the challenge for the next few days.

Again, however, Cisco felt it necessary to keep SCCP and SIP phone configuration completely seperate in the IOS. Whilst those familiar with SCCP will feel quite at home in the ‘telephony-service’ sub-mode, you’ll notice when configuring CME to register SIP phones, all the commands are spread across a multitude of sub-menus that all begin with ‘voice’. No telephony-service in sight!

..Wouldn’t it have been easier to create a ‘sip-telephony-service’ sub-mode, Cisco? :/

On top of all this, I’m starting to think we might just need CME 4.1. 12.4 XJ releases are the only IOS I’ve heard of which carry this version, and it doesn’t appear to be on the feature selector – so finding this mythical beast might be a bit harder. Cisco do list a lot of SIP commands as being only supported in CME 4.1 though, so I guess we’ll have to wait and see where the limits are!

Cisco reading

I’ve got a huge amount of reading ahead of me in the next two (and a bit) weeks. My CCNP 1 and CCNP 2 online exams, as well as the University exams for the corresponding modules (the questions being merely a rip from the online Cisco material, of course) command a mind-numbing barrage of reading.

If it wasn’t for the following websites (TFW), I’d have gone quite mad (GQM) by now. Cisco don’t half use some evil acronyms (SEA), you know.

UK Bass Radio
D’n'B Radio
Bass Drive

Alas, it’s time to stop procrastinating (TTSP) and continue reading the fine material (RTFM) as provided by Cisco!