Force background image to Cisco IP Phones

I have tested this on a 7971G and seems to work just fine.

1) Set the ssh username and password on your phones via callmanager:
https://supportforums.cisco.com/docs/DOC-13692

2) Log into your ip phone
ssh ipaddressofyourphone

3) tftp the image you want from callmanager to your phone:

tftp -s 192.168.1.10 Desktops/320x212x12/yourimage.png /flash0/Desktop

Where "192.168.1.10" represents your tftp server
"Desktops/320x196x4/yourimage.png" is the path to the file. Keep in mind
that different models have different default tftp paths and image formats.
Google your model number and "background image" and you will find the
admin guide for your phone and all that is needed.

Also note that most simple linux commands work, in terms of navigating the
filesystem and cat'ing files etc. I suppose you could push a ringtone here
as well.

Jumbo Frames Considerations

I have been doing some research and testing, and have made the following
discoveries:

1) Jumbo frames are not necessarily enabled on all switches and routers
2) Above fact doesn't mean anything is broken. Lowest common denominator
is MTU of 1500. 99% of hosts are set to 1500 anyway.
3) Any TCP session will use the mechanism called MSS (Maximum Segment
Size) to determine how big the packet size can be. It sends segments,
packaged into packets, which in turn gets packaged into frames (remember
studying for CCNA? TCP=Segment-->IP=Packet-->Ethernet=Frame). This could
result in dropped traffic only if both hosts are Jumbo frame enabled (they
would tell each other they are capable of sending large segments), but
somewhere in the path there is a link that is MTU 1500. When this happens,
that device is *supposed* to send an ICMP Need Fragmentation message, but
that doesn't always happen.

Consider the following examples:

1)
Host-----Switch---Host
1500 1500 1500
No problems here

2)
Host-----Switch---Host
9000 1500 1500
No problem here because TCP from the MTU 1500 host will tell the other
host to send smaller segments

3)
Host-----Switch---Host
1500 9216 1500
No problems here

4)
Host-----Switch---Host
9000 9216 1500
No Problem - same as option 2

5)
Host-----Switch---Host
9000 1500 9000
Umm, this could be a problem. The switch is supposed to send ICMP Need
Fragment message to the sending host if it sees jumbo frames. I hope that
the upper layer protocol is smart enough to know that when there are no
responses to change the segment size in TCP... Basically this scenario
forces me to double check all interfaces and vlans in the environment to
ensure they support Jumbo frames, or guarantee that ICMP Need Fragment
messages will be sent.

All that being said, I enabled jumbo frames (MTU 9000) on two VMs on the
same host and here is how we test:

Ping -f -l 8950 hostname

Result will show:
Reply from 192.168.1.10: bytes=8950 time=79ms TTL=128
Reply from 192.168.1.10: bytes=8950 time=1ms TTL=128
Reply from 192.168.1.10: bytes=8950 time=1ms TTL=128
Reply from 192.168.1.10: bytes=8950 time=1ms TTL=128

If for some reason jumbo frames are not allowed somewhere in the path, you
will either get

Packet needs to be fragmented but DF set.

Or

Request timed out.

Operation Failed. Fabric is already locked

I ran into this error recently on a Cisco MDS 9000 series switch. It should work on any of the switches in the line, from the MDS 9216 through MDS 9500 series storage switches.

The problem occurs when you are trying to update the device-database. It works fine until you try to device-alias commit, then the error appears. The problem is that someone else was probably trying to update the device-alias database through either the cli or fabric manager. They then exited their session without commiting the change.

To resolve the issue, issue 'show cfs lock' to show the current sessions, then 'clear device-alias session' to remove the offending session.

You should now be able to add your new device-alias and device-alias commit to submit the change.

Enjoy.

Mystery L2L VPN Dropping

I had an interesting issue where a site to site VPN drops, sometimes 5-6 times a day. There was some high bandwith during some of these drops at one of the sites, and I thought... this is DSL not frame relay. High bandwidth couldn't cause the VPN to drop, could it? Well, I opened a TAC case and the result was - we found in the logs:


Feb 07 2011 09:21:05: %ASA-5-713259: Group = 192.168.1.1, IP = 192.168.1.1, Session is being torn down. Reason: Lost Service

The important part here is "Reason: Lost Service" The TAC engineer stated this is likely because the DSL went down for a few seconds. Users haven't complained about it yet, but we will see. Changing carriers soon.

CISCO-POP-MGMT-MIB not supported on Cisco ISR Platform

Wow, this is really frustrating. Here is the simple problem: I have several T1 and E1 PRI interfaces each in several gateways. I want to track DS0 usage (call usage) for these voice circuits. These are MGCP gateways. Sounds like a job for SNMP right? Well, do you get this data from the gateway, or callmanager? Neither. I have had several suggestions for how to get it, and the only reliable answer?

RTMT. Ugg.

Anyway, I did find that under CISCO-POP-MGMT-MIB there is an OID called cpmDS1ActiveDS0s that is supposed to get exactly what I'm looking for, but was unfortunately designed for the AS5XXX platforms and looks for X/X where the ISR platforms use X/X/X. The good news is that the first controller does report back the correct data (0/0/0), but if you only have one gateway, then the OID cpmActiveDS0s will work for you as this one gives the total calls for the entire gateway (which I am using for now, but does not break it down as I would like per T1/E1 PRI).

Waiting on TAC to tell me that it is either not possible, not supported, or worse to use RTMT.

So, what do people use to track call volume on a per gateway interface basis? I do not want to switch to using H323 gateways just for this feature.

Lotus Notes Sucks

CallManager Trace: Update

When downloading trace files for callmanager, you may notice that you have two sets of files: SDI and SDL. I set out to get the definition of these acrynyms, and found the following:

SDI: System Diagnostic Interface
SDL: Signaling Distribution Layer

I think this helps to explain why you want to look in SDL for tracing call info!