Network City

ISDN PRI back-to-back

2010-07-18T01:02:00.000-07:00

To emulate a PSTN router, we need a back to back E1 connection and the obviously the first step would be the cable connecting both routers. Here, the idea is to connect HQ Router with PSTN router and therefore the crossover cable needs to be made.

Following should be the PIN Configuration; RJ-48 Connector to RJ-48 Connector (Crossover) Pinout:

1 RX Ring - -> 4 TX Ring -
2 RX Tip + -> 5 TX Tip +
4 TX Ring - -> 1 RX Ring -
5 TX Tip + -> 2 RX Tip +

When connected, both 1MFT-E1 cards have immediatly turned on the "CD" Carrier Detect light,

The basic configuration to emulate a PSTN Pri will be:

PSTN_RTR#

network-clock-participate wic 0

controller E1 0/0/0
clock source internal ---- the "pstn network" side must provide clock
pri-group timeslots 1-31

interface Serial0/0/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-net5

isdn protocol-emulate network ---- this is the PSTN-emulated side ‘Service Provider’

isdn incoming-voice voice

no cdp enable

HQ_RTR#

network-clock-participate wic 0

controller E1 1/0/0
pri-group timeslots 1-31

interface Serial1/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
!

Reference: http://www.juniper.net/techpubs/hardware/m40/m40-hwguide/html/pinout4.html

http://www.techexams.net/forums/ccvp/31284-back-back-pri-am-i-missing-something.html

http://ccvp.org/modules/newbb/viewtopic.php?topic_id=63&forum=19

http://rizzitech.blogspot.com/2009/02/wvic-1mft-e1-back-to-back-connection.html

https://supportforums.cisco.com/message/3135483

Default DHCP lease and CUCM 7.0 DHCP rebinding

2010-07-18T00:03:00.000-07:00

Default DHCP Lease
Configuring the Address Lease Time

By default, each IP address assigned by a DHCP server comes with a one-day lease, which is the amount of time that the address is valid. To change the lease value for an IP address, use the following command in DHCP pool configuration mode:

Command	Purpose
Router(config-dhcp)# lease {days [hours][minutes] \| infinite}	Specifies the duration of the lease. The default is a a one-day lease.

http://cisco.biz/en/US/docs/ios/12_0t/12_0t1/feature/guide/Easyip2.html#wp22915

CUCM 7.0 DHCP rebinding

Rebinding Timer (T2) Expires

If the client receives no reply from the server, it will remain in the RENEWING state, and will regularly retransmit the unicast DHCPREQUEST to the server. During this period of time, the client is still operating normally, from the perspective of its user. If no response from the server is received, eventually the rebinding timer (T2) expires. This will cause the client to transition to the REBINDING state, the T2 timer is set to 87.5% (7/8ths) (as per cisco’s recommendation it should be 75% of the lease time) of the length of the lease.

Client Sends DHCPREQUEST Rebinding Message

Having received no response from the server that initially granted the lease, the client “gives up” on that server and tries to contact any server that may be able to extend its existing lease. It creates a DHCPREQUEST message and puts its IP address in the CIAddr field, indicating clearly that it presently owns that address. It then broadcasts the request on the local network.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_1_2/ccmcfg/b02dhsrv.html

Writing a network report

2010-05-28T23:11:00.000-07:00

Excellent Reource on the subject,

Top Down Network Design by Priscilla Oppenheimer
http://www.topdownbook.com/

John Lockie
Here9s my advice 1. Monitor: use SNMP to gather A) interface bandwidth, B) CPU, and C) interface errors. Check the manufacturer for MIB9s to do this. If setting up SNMP is intimidating to you, contact Logic Monitor http://www.logicmonitor.com who I happen to know, but I am sure there are others that do this. Use 14 day trial if you don9t have funds or authority to authorize. 2. Document: document your findings...how hard is this? When you see an interface is at 90% utilization state it plainly, and then provide a solution such as LACP. Include a task cost dollar value (and include buffer room on the cost, don9t forget to consider labor, cabling, equipment, warranty, SmartNET, etc.). It may be that management is not even asking you for costs, in which case your job is 10x easier. 3. Summarize: reports that will go in front of executive eyeballs needs to have 3executive summary2 (hence the term). Their time is valuable, so cut to the chase on page 1 and leave the rest of the reading for the nerdy or even 3doubting2 executives :) That9s all you probably need to include. If you want to go crazy (like if your switch network is going to cost you a million to upgrade) then it might be wise to really dive in to vendor technologies, the differences between HP and Cisco at L2 level, etc. Go nuts if you decide to do this, the more the better - just don9t forget your executive summary, because some guys could care less. Some other advice I can give you, as a manager who reports to executives.... 1. Keep yourself out of the equation, think for the business. By thinking for the business interest you are in the long run thinking for your own. 2. Ask management the same question you asked us. 3What do you expect to see included in this report2. You may be surprised. Every time I am given a directive from executives I ask them, 3what you do expect to see2. There is no shame in asking, and it9s actually dangerous not to ask. Sometimes they want only a price, and other times they want the entire enchilada. My points above assumed somewhere between those two.... One other thing....since you said 4500 series. Why not stackable 3700 series? :). Be careful here....while you are comparing old to new, you need to know why you would do 1 new over another new. For example, it might be obvious you need to upgrade switched network. But is it obvious why you pick Catalyst over Procurve? A discriminating executive who knows even a little (or lives next door to a VP for Procurve division!) could really challenge you on this one. Here is a tip, simply look closely at things like ISL over 802.1Q, and you may find that arguing for Cisco protocols is a little more justified. Good luck, John

COR List and Translation rules

2010-05-27T12:56:00.000-07:00

In this lab we tried to use two functions translation rules and COR list
translations being used to transform the number from PSTN to local extention and COR was used to restrict the caller whom they can call or whom they cannot.

First of all we planned our dial plan, as you know we have been using two routers one is CME which have one sip and sccp phone and other router name CME-SIP that does have two SIP phones

Here, we just used one SIP Phone 4001 @ CME router and one SIP Phone 6001 @ CME-SIP router, like that;

4001--------------CME----------------CME-SIP----------------6001

below is the COR config that we used in this scenario

The below configuration for COR has been done on the CME side as needed

1) Defining cor list members
dial-peer cor custom
name local_KAR
name LD_LHR
name LongDist
name international

2) -------- Outgoing Corlists
dial-peer cor list KAR
member local_KAR

dial-peer cor list LHR
member LD_LHR

dial-peer cor list LD
member LongDist

dial-peer cor list INT
member international

3)----- incoming corlists

dial-peer cor list LongD
member local_KAR
member LD_LHR

dial-peer cor list Local
member local_KAR

4) applying outgoing corlist to dial peers

dial-peer voice 9042 voip
corlist outgoing LHR
destination-pattern 9042[39].......
session protocol sipv2
session target ipv4:172.16.1.2
dtmf-relay rtp-nte
codec g711ulaw

5) applying incoming corlist to ip phones

voice register pool 1
corlist incoming LongD

we also tried with
voice register pool 1
corlist incoming Local

When a caller dials 9042........ number it gets transformed to 042........ number basically eliminates the '9' digit so here we were emulating a PSTN call using the below translation rule and profile @ CME router

voice translation-rule 30
rule 1 /^9\(042[39].......\)/ /\1/
rule 2 /^9\([39].......\)/ /\1/

voice translation-profile lhr
translate called 30 ---- here translating a called number i.e DNIS

applying translation profile to dial-peer

dial-peer voice 9042 voip
translation-profile outgoing lhr
destination-pattern 9042[39].......
session protocol sipv2
session target ipv4:172.16.1.2
dtmf-relay rtp-nte
codec g711ulaw
corlist outgoing LHR

Now when digit passes to CME-SIP router provided the SIP Phone 4001 has the authorized cor list to continue. So when it recieves number starting from 042 it basically matches the following dial-peer;

dial-peer voice 42 voip
translation-profile incoming local_Profile
session protocol sipv2
incoming called-number 042........
dtmf-relay rtp-nte
codec g711ulaw

here u noticed we have used the translation profile so that once it matches the incoming called number it basically transforms its number to local number i.e 6001. Lets see how

voice translation-rule 500
rule 1 /^[39]......./ /5001/
rule 2 /^042[39]......./ /6001/

voice translation-profile local_Profile
translate called 500

So following the rule it matches rule 2 and rings the 6001 phone. Simple isn't it ;)

@ Cme side we tested with two incoming cor list to 4001 to test the function first we apply
voice register pool 1
corlist incoming LongD -- that basically through the call

we also tried with;

voice register pool 1
corlist incoming Local -- that basically blocked the call

HTH

Regards

Configuring SIP Gw and H.323 Gw

2010-05-02T09:26:00.000-07:00

That was bit tough to actually make it happen.. Well i will just elaborate first what here we exactly wanted to test.

The task was to call from SIP to SCCP Phone and vice versa

Well actually i was testing a scenario in my lab, where i was using two cme routers. One configured as SIP gateway and other as an H323 gateway.

On the H323 router i only have configured SCCP phones but on other one just the SIP phone using 3cx. exten of SIP phone was 5001 and for SCCP it was 3001

I initially could calls from SIP phone to SCCP but cant make from SCCP to SIP.

Even though respected voip dial-peers were created and voip service voip command configured with sip to h323 and vice versa but that didn't give me a joy....

Lets look what actually i did

--On h323 gateway;

voice service voip
allow-connections h323 to sip
allow-connections sip to h323

!
ephone-dn 3
number 3001
label first_3001

ephone 3
device-security-mode none
mac-address 0200.4C4F.4F52
type CIPC
button 1:3

!
dial-peer voice 50 voip
destination-pattern 5...
session target ipv4:172.16.1.2
dtmf-relay rtp-nte

----On SIP gateway;

voice service voip
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
sip
registrar server
!

!
voice register dn 1
number 5001
allow watch
name 3cx
!
voice register pool 1
id mac 0200.4C4F.4F54
number 1 dn 1
username test password test
codec g711ulaw

dial-peer voice 30 voip
destination-pattern 3...
session target ipv4:172.16.1.1

After spending alot of time digging into incoming and outgoing dial-peers..how they actually works ...I finally got it all working...yeaaah.

I actually was missing the right codecs Now the below configs works just perfect . Now i do have calls from both ends.

SIP

dial-peer voice 30 voip ----- thats an outgoing dial peer
destination-pattern 3...
session target ipv4:172.16.1.1
codec g711ulaw

SIP# sh voice register pool 1 --- output

dial-peer voice 40001 voip --- the implicit dial-peer created for incoming calls
destination-pattern 5001
session target ipv4:192.168.2.10:58855
session protocol sipv2
codec g711ulaw bytes 160

H323

dial-peer voice 50 voip ----- thats an outgoing dial peer
destination-pattern 5...
session protocol sipv2
session target ipv4:172.16.1.2
dtmf-relay rtp-nte
codec g711ulaw

Also there is the output of the 'debug voice dialpeer all' that helped me alot

---------------AT SIP GW---------

Mar 1 00:31:05.599: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Calling Number=, Called Number=5001, Peer Info Type=DIALPEER_INFO_SPEECH
*Mar 1 00:31:05.599: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Match Rule=DP_MATCH_DEST; Called Number=5001
*Mar 1 00:31:05.603: //-1/xxxxxxxxxxxx/DPM/dpMatchCore:
Dial String=5001, Expanded String=5001, Calling Number=
Timeout=TRUE, Is Incoming=FALSE, Peer Info Type=DIALPEER_INFO_SPEECH
*Mar 1 00:31:05.611: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:
Result=Success(0); Outgoing Dial-peer=40001 Is Matched
*Mar 1 00:31:05.619: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
*Mar 1 00:31:05.619: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=40001

---------------AT H323 GW---------

Dial String=5001, Expanded String=5001, Calling Number=
Timeout=TRUE, Is Incoming=FALSE, Peer Info Type=DIALPEER_INFO_SPEECH
*Mar 1 00:31:09.251: //-1/xxxxxxxxxxxx/DPM/MatchNextPeer:
Result=Success(0); Outgoing Dial-peer=50 Is Matched
*Mar 1 00:31:09.255: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
Result=Success(0) after DP_MATCH_DEST
*Mar 1 00:31:09.259: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
Result=SUCCESS(0)
List of Matched Outgoing Dial-peer(s):
1: Dial-peer Tag=50
*Mar 1 00:31:09.263: //13/6C99EB548014/CCAPI/ccCallFeature:
Feature Type=25, Call Id=13

Reference

https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/1765-102-2-2583/UC500-CCA-First-Look-v1.3-Lab8B.pdf

http://www.ciscopress.com/articles/article.asp?p=664148&seqNum=6

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml

https://supportforums.cisco.com/thread/136551

HTH

Configuring B-ACD services

2010-04-19T02:18:00.000-07:00

Configuring B-ACD services was one of the task that we wanted to look deep into it and for that we read the following comprehensive guide which was a key to got it configured successfully.

Reference:
http://cisco.biz/en/US/docs/voice_ip_comm/cucme/bacd/configuration/guide/40bacd.html
http://cciev.wordpress.com/2006/05/29/cme-b-acd/
http://www.voiceie.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=8;t=000692

Here are the steps which were followed;

-- Creating ephone-hunt groups --

ephone-hunt 15 longest-idle
pilot 2000
list 2001, 2002
timeout 10, 10
!
!
!
!
ephone-hunt 16 sequential
pilot 3000
list 3001
timeout 20

-- Configuring AA scripts --
I had to download the whole b-acd-2.1.2.2.tar file to my flash first which consist of the following two tcl scipts
app-b-acd-2.1.2.2.tcl
app-b-acd-aa-2.1.2.2.tcl

through config terminal some mandatory parameters being defined as follows

application
service queue flash:app-b-acd-2.1.2.2.tcl --- named the service name as queue
param number-of-hunt-grps 2 --- we are using 2 hunt groups as earlier defined
param aa-hunt1 2000
param aa-hunt2 3000
param queue-len 15
param queue-manager-debugs 1 --- used with debug command to trace the script

service aa flash:app-b-acd-aa-2.1.2.2.tcl --- named the service name as aa
paramspace english index 1
paramspace english language en
paramspace english location flash:
param service-name queue --- refrencing the service name queue defined earlier
param handoff-string aa
param aa-pilot 1000 --- using pilot number 1000 for which we will define
the dial-peer accordingly
param welcome-prompt _bacd_welcome.au
param number-of-hunt-grps 2
param dial-by-extension-option 3 --- defining the dial by extention option as 3 explicitly

param max-extension-length 4
param second-greeting-time 30
param call-retry-timer 15
param max-time-call-retry 100
param max-time-vm-retry 2
param voice-mail 1002

-- Creating a VOIP dial-peer --

When someone dials the number 1000 it would initiate this dial-peer and the aa service will get activated. the 20.0.0.1 is the loopback address defined for CME

dial-peer voice 1000 voip
service aa
destination-pattern 1000
session target ipv4:20.0.0.1
incoming called-number 1000
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad

-- Now Some diagnostic commands --

CME#call application voice load aa --- loading aa service ( you will need to load this service if you have changed the pre=defined parameters or have added other parameters)

CME#
*Mar 1 00:25:08.519: //-1//HIFS:/hifs_ifs_cb: hifs ifs file read succeeded. size=35485, url=flash:app-b-acd-aa-2.1.2.2.tcl
*Mar 1 00:25:08.539: //-1//HIFS:/hifs_free_idata: hifs_free_idata: 0x67DAA108
*Mar 1 00:25:08.539: //-1//HIFS:/hifs_hold_idata: hifs_hold_idata: 0x67DAA108
*Mar 1 00:25:08.739: //-1//TCL :EE66B155AC000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter second-greeting-time = 30 --
*Mar 1 00:25:08.787: //-1//TCL :EE66B155AC000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter call-retry-timer = 15 --
*Mar 1 00:25:08.855: //-1//TCL :EE66B155AC000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter max-time-call-retry = 100 --
*Mar 1 00:25:08.895: //-1//TCL :EE66B155AC000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter max-time-vm-retry = 2 --
*Mar 1 00:25:08.951: //-1//TCL :EE66B155AC000:/tcl_PutsObjCmd: TCL AA: -- Valid Mandatory parameter number-of-hunt-grps = 2 --

CME#call application voice load queue --- loading queue service

CME#
*Mar 1 00:25:43.759: //-1//HIFS:/hifs_ifs_cb: hifs ifs file read succeeded. size=24985, url=flash:app-b-acd-2.1.2.2.tcl
*Mar 1 00:25:43.767: //-1//HIFS:/hifs_free_idata: hifs_free_idata: 0x67DAA198
*Mar 1 00:25:43.771: //-1//HIFS:/hifs_hold_idata: hifs_hold_idata: 0x67DAA198
*Mar 1 00:25:44.031: //-1//TCL :EE66B15694000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid optional parameter queue-manager-debugs = 1 --
*Mar 1 00:25:44.071: //-1//TCL :EE66B15694000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid Mandatory parameter queue-len = 15 --
*Mar 1 00:25:44.147: //-1//TCL :EE66B15694000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid Mandatory parameter number-of-hunt-grps = 2 --

CME#sh call application sessions -- nothing showed up as we havn't initiated any call to pilot number yet

CME#debug voice application script -- you can see if you getting hits on the application

CME#csim start 1000 --- testing pilot number of aa 1000

csim: called number = 1000, loop count = 1 ping count = 0

*Mar 1 00:26:21.647: //-1//TCL :EE66B1577C000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter second-greeting-time = 30 --
*Mar 1 00:26:21.711: //-1//TCL :EE66B1577C000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter call-retry-timer = 15 --
*Mar 1 00:26:21.747: //-1//TCL :EE66B1577C000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter max-time-call-retry = 100 --
*Mar 1 00:26:21.795: //-1//TCL :EE66B1577C000:/tcl_PutsObjCmd: TCL AA: -- Valid mandatory parameter max-time-vm-retry = 2 --
*Mar 1 00:26:21.835: //-1//TCL :EE66B1577C000:/tcl_PutsObjCmd: TCL AA: -- Valid Mandatory parameter number-of-hunt-grps = 2 --
*Mar 1 00:26:21.983: //6//TCL :/tcl_PutsObjCmd:
proc init_perCallvars
*Mar 1 00:26:21.987:
*Mar 1 00:26:22.055: //6//TCL :/tcl_PutsObjCmd: TCL AA: +++ B-ACD-SERVICE not registered, Starting B-ACD-SERVICE +++
*Mar 1 00:26:22.519: //-1//TCL :EE66B15864000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid optional parameter queue-manager-debugs = 1 --
*Mar 1 00:26:22.551: //-1//TCL :EE66B15864000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid Mandatory parameter queue-len = 15 --
*Mar 1 00:26:22.591: //-1//TCL :EE66B15864000:/tcl_PutsObjCmd: TCL B-ACD: -- Valid Mandatory parameter number-of-hunt-grps = 2 --
*Mar 1 00:26:22.863: %IVR-6-APP_INFO: TCL B-ACD: >>> B-ACD Service Started <<< *Mar 1 00:26:22.871: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> B-ACD Service Started <<< *Mar 1 00:26:22.907: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Handoff String = aa <<< *Mar 1 00:26:22.975: //6//TCL :/tcl_PutsObjCmd: proc init_perCallvars *Mar 1 00:26:22.979: *Mar 1 00:26:23.175: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Stat collection disabled for queue 2000 <<< *Mar 1 00:26:23.227: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: ++ Message received from IOS ++ *Mar 1 00:26:23.255: //6//TCL :/tcl_PutsObjCmd: TCL AA: ++ Playing Welcome Prompt and options menu ++ *Mar 1 00:26:26.363: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: ++ Message received from IOS ++ *Mar 1 00:26:26.435: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: >>> Stat collection disabled for queue 3000 <<<
*Mar 1 00:26:26.443: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: ++ Message received from IOS ++
*Mar 1 00:26:26.495: //6//TCL :/tcl_PutsObjCmd: TCL B-ACD: ++ Message received from IOS ++
*Mar 1 00:26:45.843: //6//TCL :/tcl_PutsObjCmd: TCL AA: +++ No option selected +++.
csim: loop = 1, failed = 0
csim: call attempted = 1, setup failed = 0, tone failed = 1

---After we placed a call from softphone to pilot 1000 and during the call we ran the following command with output as follows--

CME#sh call application sessions
Session ID 4

App: queue
Type: Service
Url: flash:app-b-acd-2.1.2.2.tcl

Session ID 8

App: aa
Type: Service
Url: flash:app-b-acd-aa-2.1.2.2.tcl

________________________________________________________

Righsizing CME/SRST

2010-04-15T22:11:00.000-07:00

Below is the max ephone numbers per platform as the results of this commit

1. 2811 : CME 42 / SRST 42
2. 2821 : CME 58 / SRST 58
3. 2851 : CME 110 / SRST 110
4. 2801 : CME 30 / SRST 30
5. 3825 : CME 185 / SRST 340
6. 3845 : CME 262 / SRST 720

Cisco Unified CME VoIP Call Transfer Options

2010-03-21T23:11:00.000-07:00

Your Cisco Unified CME system by default is set up to allow local transfers between IP phones only. It
uses the Cisco H.323 call transfer extensions to transfer calls that include an H.323 VoIP participant.
To configure your Cisco Unified CME system to use H.450.2 transfers (this is recommended), set
transfer-system full-consult under the telephony-service command mode. You also have to use this
configuration for SIP VoIP transfers.
To configure your Cisco Unified CME system to permit transfers to nonlocal destinations (VoIP or
PSTN), set the transfer-pattern command under telephony-service. The transfer-pattern command
also allows you to specify that specific transfer-to destinations should receive only blind transfers. You
also have to use this configuration for SIP VoIP transfers. The transfer-pattern command allows you to
restrict trunk-to-trunk transfers to prevent incoming PSTN calls from being transferred back out to the
PSTN (employee toll fraud). Trunk-to-trunk transfers are disabled by default, because the default is to
allow only local extension-to-extension transfers.
To allow the H.450.12 service to automatically detect the H.450.2 capabilities of endpoints in your
H.323 VoIP network, use the supplementary-services command in voice service voip command mode.
To enable hairpin routing of VoIP calls that cannot be transferred (or forwarded) using H.450, use the
allow-connections command. The following example shows a call transfer configuration using this
command.
voice service voip
   supplementary-service h450.12
   allow-connections h323 to h323
telephony-service
   transfer-system full-consult
   transfer-pattern .T
The configuration shown in the preceding example turns on the H.450.2 (transfer-system full-consult)
and H.450.12 services, allows VoIP-to-VoIP hairpin call routing (allow-connections) for calls that don’t
support H.450, and permits transfers to all possible destinations (transfer-pattern). The transfer
permission is set to .T to provide full wildcard matching for any number of digits. (The T stands for
terminating the transfer destination digit entry with a timeout.)

The following example shows a configuration for more restrictive transfer permissions.
telephony-service
   transfer-system full-consult
   transfer-pattern 1...
   transfer-pattern 2... blind
This example permits transfers using full consultation to nonlocal extensions in the range 1000 to 1999.
It also permits blind transfers to nonlocal extensions in the range 2000 to 2999.

Notes Regarding H.450.12 and ECS

H.450.12
You can compromise between the H.450.2 and hairpin routing call methods by turning on the H.450.12
protocol on your Cisco Unified CME system (this is recommended). You must be using at least
Cisco Unified CME 3.1 to use H.450.12. With H.450.12 enabled, your Cisco Unified CME system can
use the H.450.12 protocol to automatically discover the H.450.x capabilities of VoIP endpoints within
your VoIP network. When H.450.12 is enabled, the Cisco Unified CME system can automatically detect
when an H.450.2 transfer is possible. When it isn’t possible, the Cisco Unified CME system can fall back
to using VoIP hairpin routing. Cisco Unified CME also can automatically detect a call from a
(non-H.450-capable) Cisco Unified CallManager.

Empty Capabilities Set
For the sake of completeness, it is worth mentioning a fourth alternative for call transfers: Empty
Capabilities Set (ECS). Cisco Unified CME does not support the instigation of transfer using ECS. But
because a Cisco Unified CME router also has the full capabilities of the Cisco IOS Release H.323 voice
infrastructure software, it can process receipt of an ECS request coming from a far-end VoIP device. In
other words, a Cisco Unified CME system can be a transferee or transfer-to party in an ECS-based
transfer. A Cisco Unified CME system does not originate a transfer request using ECS. The problem with
ECS-based transfers is that in many ways they represent a combination of the worst aspects of the
end-to-end dependencies of H.450.2 together with the cumulative problems of hairpin for multiple
transfers. Many ECS-based transfer implementations do not allow you to transfer a call that has already
been transferred in the general case of VoIP intersystem transfers.

Disclaimer : The Extract is from Cisco Systems Documentation

Demystifying Mpps

2010-03-08T03:50:00.000-08:00

Throughput Parameter regarding switches has always been an ambiguity, finally i manage to crack it, with some help from guislar and ganesh @ Cisco Netpro.

2960-48PST-S -- 13.3 Mpps

The figure Mpps expresses the maximum number of frames per second that can be processed by the device.
It is not dependent on frame size but clearly small frames require higher packet rates.

To give you an idea of what this number says:
smallest frames in ethernet are 64 bytes in size, taking in account the preamble (8 bytes) and the minimum interframe gap (the last two counts roughly for 20.2 bytes) to fill a GE port in one direction you need
1484560 frame per second.

10^9 / [(64+20,2)*8]

where 8 is bits/byte

so a number of 13.3 Mpps is equivalent to ((13.3 M * (64+20.2) * 8 )) / 10^9 = 8.95 / 2 = 4.47 GE ports filled with smallest frames bidirectional.

on the other hand frames of max size 1518 bytes require 81264 fps to fill a GE port in one direction.

So this number expresses the forwarding capability of the device.
A non blocking device with 48 GE ports would require 2 * 1484560 * 48 as Mpps or higher.

A device like C2960 can be classified as centralized CEF forwarding.

Mpps regarding routers,

MPPS stands for million packets per second and Cisco prefers to refer throughput in MPPS.For a layer-3 switch an Mpps value is shared one. For some of the higher-end cisco routers the routing is "distributed" between multipe line-cards, in which case the PPS numbers are based on the number of line cards, bit for non-distributed architectures (Catalyst switches) the numbers are based on the routing engine, so it is the maximum number of Packets Per Second that the box can route.

and as giuslar said 2960 switches are centralized cef based forwarding.

Switching capacity vs Throuhput

Cisco Catalyst 4900 Series Switch Model Comparison for Fiber Aggregation

Feature and Description	Cisco Catalyst 4928 10 Gigabit Ethernet Switch
Switch Capacity	96 Gbps
Throughput	71 mpps

Switching capacity is some times given as the amount of frames a switch can deal with over a given time frame and throughput on the other hand means how much actually data can cross the switch in a given time frame.

Jumbo Frames Demystified

2010-02-24T01:04:00.000-08:00

The Promise and Peril of Jumbo Frames

We sit at the intersection of two trends:

Most home networking gear, including routers, has safely transitioned to gigabit ethernet.
The generation, storage, and transmission of large high definition video files is becoming commonplace.

If that sounds like you, or someone you know, there's one tweak you should know about that can potentally improve your local network throughput quite a bit -- enabling Jumbo Frames.
The typical UDP packet looks something like this:

But the default size of that data payload was established years ago. In the context of gigabit ethernet and the amount of data we transfer today, it does seem a bit.. anemic.

The original 1,518-byte MTU for Ethernet was chosen because of the high error rates and low speed of communications. If a corrupted packet is sent, only 1,518 bytes must be re-sent to correct the error. However, each frame requires that the network hardware and software process it. If the frame size is increased, the same amount of data can be transferred with less effort. This reduces CPU utilization (mostly due to interrupt reduction) and increases throughput by allowing the system to concentrate on the data in the frames, instead of the frames around the data.

I use my beloved energy efficient home theater PC as an always-on media server, and I'm constantly transferring gigabytes of video, music, and photos to it. Let's try enabling jumbo frames for my little network.
The first thing you'll need to do is update your network hardware drivers to the latest versions. I learned this the hard way, but if you want to play with advanced networking features like Jumbo Frames, you need the latest and greatest network hardware drivers. What was included with the OS is unlikely to cut it. Check on the network chipset manufacturer's website.
Once you've got those drivers up to date, look for the Jumbo Frames setting in the advanced properties of the network card. Here's what it looks like on two different ethernet chipsets:

That's my computer, and the HTPC, respectively. I was a little disturbed to notice that neither driver recognizes exactly the same data payload size. It's named "Jumbo Frame" with 2KB - 9KB settings in 1KB increments on the Realtek, and "Jumbo Packet" with 4088 or 9014 settings on the Marvell. I know that technically, for jumbo frames to work, all the networking devices on the subnet have to agree on the data payload size. I couldn't tell quite what to do, so I set them as you see above.
(I didn't change anything on my router / switch, which at the moment is the D-Link DGL-4500; note that most gigabit switches support jumbo frames, but you should always verify with the manufacturer's website to be sure.)
I then ran a few tests to see if there was any difference. I started with a simple file copy.
Default network settings

Jumbo Frames enabled

My file copy went from 47.6 MB/sec to 60.0 MB/sec. Not too shabby! But this is a very ad hoc sort of testing. Let's see what the PassMark Network Benchmark has to say.
Default network settings

Jumbo Frames enabled

This confirms what I saw with the file copy. With jumbo frames enabled, we go from 390,638 kilobits/sec to 477,927 kilobits/sec average. A solid 20% improvement.
Now, jumbo frames aren't a silver bullet. There's a reason jumbo frames are never enabled by default: some networking equipment can't deal with the non-standard frame sizes. Like all deviations from default settings, it is absolutely possible to make your networking worse by enabling jumbo frames, so proceed with caution. This SmallNetBuilder article outlines some of the pitfalls:

1) For a large frame to be transmitted intact from end to end, every component on the path must support that frame size. The switch(es), router(s), and NIC(s) from one end to the other must all support the same size of jumbo frame transmission for a successful jumbo frame communication session.
2) Switches that don't support jumbo frames will drop jumbo frames.
In the event that both ends agree to jumbo frame transmission, there still needs to be end-to-end support for jumbo frames, meaning all the switches and routers must be jumbo frame enabled. At Layer 2, not all gigabit switches support jumbo frames. Those that do will forward the jumbo frames. Those that don't will drop the frames.
3) For a jumbo packet to pass through a router, both the ingress and egress interfaces must support the larger packet size. Otherwise, the packets will be dropped or fragmented.
If the size of the data payload can't be negotiated (this is known as PMTUD, packet MTU discovery) due to firewalls, the data will be dropped with no warning, or "blackholed". And if the MTU isn't supported, the data will have to be fragmented to a supported size and retransmitted, reducing throughput.

In addition to these issues, large packets can also hurt latency for gaming and voice-over-IP applications. Bigger isn't always better.
Still, if you regularly transfer large files, jumbo frames are definitely worth looking into. My tests showed a solid 20% gain in throughput, and for the type of activity on my little network, I can't think of any downside.

Comments Worth Noting:

i have been building networks for broadcasters for over a decade - who always wanted bigger / faster / more type networks.
jumbo frames are great in theory, but the pain level can be very high.
A core network switch can be brought to its knees when 9 Kbyte frames have to be fragmented to run out a lower MTU interface.
Many devices dont implement PMTU correctly, or just ignore responses - video codecs seem particularly prone to this.
and wasnt there a discussion a few newsletters ago about dont try to optimise things too much? If you need 20% more network performance, but you are only operating at maybe 40% load, then you need a faster machine or a better NIC card.
And there have been something like 5 definitions of jumbo just in the cisco product line. Also telecomms manufacturers idea of jumbo often have frames with 4 Kbytes, not 9 Kbytes.....
And just to set the record straight - the reason for the 1514 bytes frame limit in GigE and 10G ethernet is backward compatibility.
Just about every network has some 10/100 (or 10 only) equipment still, and the 1514 limit has been built into other standards such as 802.11 wireless LAN.
the old saying is that God would have struggled to make the world in 7 days if he started with an installed base...

------------------------------------------------------------------------

Just a couple things to point out.
File transfer is typically done using TCP, not UDP. TCP has more overhead than UDP.
I'm curious why we see a sawtooth pattern in the un-jumbo framed graph. Is that TCP Vegas doing its thing?
I'm glad you've gone ahead and tried this out. Jumbo frames wouldn't exist if they didn't have a purpose, but with all the different kinds of traffic I think 1500 MTU is a good choice.
One with jumbo frames that you touched on, but didn't adequately explain, is that most consumer switches use the store-and-forward method of switching packets. This means that your switch must receive the whole packet before it can send it along, it can't be doing anything else because packets can't be multiplexed. This can cause unacceptable latency (you have 2 computers, not a big deal, but between several machines all trying to send data, you can end up with some seriously delayed packets).
I just would have liked to see more reasons not to do this that it's not a supported standard and doesn't work with a lot of hardware. There are other reasons this has not become the default.

----------------------------------------------------------------------

@Bob from what I have seen IPv6 is potentially a bigger problem than IPv4, because where an IPv4 router may see that the packet is too large and fragment it, IPv6 leaves it to the end devices.

---------------------------------------------------------------------------------

Jumbo frames are great. I work on VMware ESX networking, and I will point out what may not be obvious to everyone. In a virtualized environment (hosted or hypervisor) jumbo frames make an even bigger difference, since you are doing more work per packet to begin with. That's why we added jumbo frame support since ESX 3.5 shipped.
My experience is that any recent machine can easily push full 1Gbit line rate (on native, and for that matter ESX VMs). Setting Jumbo Frames will save you on CPU though, which will allow you to run more VMs or otherwise use that power. And while Jumbo Frames are nice- they get you from 1.5k packets to 9, TCP Segmentation Offloading (TSO) is much better, since you push down entire 64k (or sometimes up to 256k) packets, and an engine on the NIC itself automatically handles dicing them into 1.5K packets. Most good nics support this- Intel, Broadcom, etc. On the other side, the reverse is LRO, or RSS, but this is more complicated and less common. Plus with TSO, you don't have to worry about MTU.
The other thing I would mention is- for the love of god, don't run networking benchmarks by doing a file copy. With 1GBit networks, you are limited by your disk speed! Run a proper tool such as iperf (brain dead simple) or netperf, which just blasts data. Even if your hard drive could reach 1Gbit speeds, you would be wasting cycles, so your networking performance would be worse. You always want to look at these things in isolation.

--------------------------------------------------------------------------------------------

The reason that all these people are seeing performance improvements using Jumbo Frame on Windows is because Windows networking stack sucks. Windows is really stupid and often will not let a single tcp stream reach the full capacity of the NIC. I.e. you run 1 TCP stream and measure 400Mbits, but if you ran 3 in parallel you would hit 940Mbits (~Line rate). This is even more annoying with 10G, since you need like 18 streams to reach the peak performance. Linux doesn't have these problems, and will give you its best possible performance on a single stream. I can only imagine Window's behavior is the result of some misguided attempt at ensuring fairness between connections by making sure that even if there is only one connection, it never uses the full capacity.

--------------------------------------------------------------------------------------------

If you simply enable jumbo frames on your NIC, every connection to any Internet destination (which don't support jumbos) will need to undergo PMTU discovery, PMTU blackhole detection, router fragmentation, or other time-consuming / performance-sapping hacks. This might explain why people complain about latency issues with gaming. These people are also seeing slightly slower peformance with all Internet activity.
*nix, as/400/, mainframes, and other operating systems let you set the frame size on a per route basis. E.g.,
route add -net 0.0.0.0 gw 192.168.0.1 mss 1460
This tells the OS to use jumbo frames only on the local LAN, and to assume a normal packet size everywhere else.
Alas, Windows has no such ability. One solution on Windows is to use two NICs attached to the same network. Have one NIC configured with normal frames and the default route. Have the second NIC configured for jumbos with no default route.

---------------------------------------------------------------------------------------

I participated in the IEEE 802.3 committee for a while. IEEE never standardized a larger frame size for two reasons that I know of:
1. The end stations can negotiate the frame size, but there was no backwards-compatible way to ensure that all L2 bridges between them can handle it. Even if you send a jumbo frame successfully, you can still run into a problem later if the network topology changes and your packets begin taking a different path through the network.
2. The CRC32 at the end of the packet becomes weaker after around 4 KBytes of data. It can no longer guarantee that single bit errors will be caught, and the multibit error detection becomes weaker as well.
One is free to enable it, and it does improve the performance, but the situation is unlikely to ever get better in terms of standard interoperability. It will always be an option to be enabled manually.
Also a number of years ago,. jumbo frames provided a much bigger boost. Going from 1.5K to 9K regularly doubled performance or more. What has happened since is smarter ethernet NICs: they routinely coalesce interrupts, steer packets from the same flow to the same CPU, and sometimes even reassemble the payload of the 1.5K frames back into larger units. The resistance to standardizing jumbo frames resulted in increased innovation elsewhere to compensate.

-----------------------------------------------------------------------------

@Timothy Layer 2 ethernet switches will just drop packets they cannot handle. It is not just if they don't handle jumbo frames: they can drop a normal size packet if their internal queues are full, or if rate limiting has been configured, or if the switch hit some other internal condition which the ASIC designer didn't bother resolving. They just drop the packet and expect the sender to retransmit. There is no mechanism for an L2 device to send back a notification that it has dropped the packet. A managed L2 switch will have some counters so you can post-mortem analyze what is wrong with your network.
Layer 3 routers will drop packets for more reasons, in addition to queue congestion. For example when the packet is too big and the don't fragment bit is set, an ICMP message is sent back (this is how path MTU discovery works). Similarly routers send back ICMP messages if they have no route to the destination.
Even the ICMP is just a best effort notification. Routers routinely limit the rate of ICMP messages they will send, to avoid having a flood of ICMP messages make a bad network problem worse. ICMP messages can also be dropped on their way back to the originator. So the best the sender can expect is it _might_ get notified of an L3 problem, sometime.

--------------------------------------------------------------------------

Disclamier: Credit to original Poster
http://www.codinghorror.com/blog/2009/03/the-promise-and-peril-of-jumbo-frames.html

Configuring LLQ and LFI on a Router

2010-02-07T05:05:00.000-08:00

LFI

Link fragmentation and interleaving, why do we need it cisco recommends that for links equal to or lower than 768 kbps needs fragmentation and interleaving for voice packets, links slower than 768 kbps consume higher serialization delay when putting a voice packet, which is inherently large, on the wire. this is recommended for higher sped links.

#access-list 102 permit udp any nay range 16384 32767
#access-list 103 permit tcp any eq 1720 any
#access-list 103 permit tcp any any eq 1720

#class-map match-all VOICE-SIGNALING
#match access-group 103
#class-map match-all VOICE-TRAFFIC
#match access-group 102

#policy-map VOICE-POLICY
#class VOICE-TRAFFIC
#priority 48
#class VOICE-SIGNALING
#bandwidth 8
#class class-default
#fair-queue

#interface multilink1
#ip address 172.22.130.1 255.255.255.252
#ip tcp header-compression iphc-format
#ip rtp header-compression iphc-format

#serivce policy output VOICE-POLICY

#ppp multilink
#ppp multilink fragment-delay
#ppp multilink interleave
#multilink-group 1

#interface serial 0/0
#multilink-group 1

Config description,

#access-list 102 permit udp any nay range 16384 32767
#access-list 103 permit tcp any eq 1720 any
#access-list 103 permit tcp any any eq 1720

in the first statement 102 we are matching UDP ports 16384 to 32767 which are responsible for carrying voice RTP payload.
in the second & third statement we are matching TCP voice signaling port 1720

#class-map match-all VOICE-SIGNALING
#match access-group 103
#class-map match-all VOICE-TRAFFIC
#match access-group 102

Relevant class maps, against configured ACL's

#policy-map VOICE-POLICY
#class VOICE-TRAFFIC
#priority 48
#class VOICE-SIGNALING
#bandwidth 8
#class class-default
#fair-queue

Policy maps are configured with relevant policies, here we have configured 48 kbps of priority bandwidth for voice traffic which is merely a single call so you should configure it according to your situation, one thing very important here the VOICE-TRAFFIC will get 48 kbps of priority bandwidth traffic exceding that will be policed, on the contrary the bandwidth command reserves minimum 8 kbps of bandwidth for VOICE-SIGNALING and it can exceed its threshold of 8 kbps whereas priority cant.

Every thing else will be treated by Weighted fair queuing (fair-queue) which penalizes high talkers i.e. sessions consuming higher bandwidth as compared to low talkers sessions consuming lower bandwidth

#interface multilink1
#ip address 172.22.130.1 255.255.255.252
#ip tcp header-compression iphc-format
#ip rtp header-compression iphc-format

We have to create interface multilink1 to enable LFI.
Then the header compressions will compress the headers accordingly.

#serivce policy output VOICE-POLICY

applies the LLQ to this interface, to be used along with LFI.

#ppp multilink
#ppp multilink fragment-delay 10
#ppp multilink interleave
#multilink-group 1

#interface serial 0/0
#multilink-group 1

the first statement enables multilink.

#ppp multilink fragment-delay 10, statement enables delay no more than 10 ms, on a 56 k link a 1500 Bytes packet takes 215 mSec to be put on the wire which is to much, we need delay something b/w 150-200 msec so fragmentation will definately help.

#ppp multilink interleave, will enable interleaving so the packets that were chip choped by fragmentation are treated voice packets are sent first always.

Then the interleaving and fragmentation is applied on the interface

Configuring LLQ Quality of service

2010-02-07T04:11:00.000-08:00

Configuring LLQ on a switch access port.

#interface fastethernet 0/1
#wrr-queue cos-map 1 0 1
#wrr-queue cos-map 2 2 3
#wrr-queue cos-map 3 4 6 7
#wrr-queue cos-map 4 5
#priority-queue out

#mls qos trust device cisco-phone
#mls cos trust cos
#switchport voice vlan 100
#switchport access vlan 10

#switchport priority extend cos 0
#mls qos map cos-dscp 0 8 16 24 34 46 48 56
#mls qos bandwidth 10 20 70 0(0 or 1)

Description and usage of each command is as follows

In this Configuration im going to configure low latency queuing on a cisco switch, applicable to access port connecting to the IP phone daisy chained to a PC.

#interface fastethernet 0/1
#wrr-queue cos-map 1 0 1
#wrr-queue cos-map 2 2 3
#wrr-queue cos-map 3 4 6 7
#wrr-queue cos-map 4 5

In the above config we have configured four queues, 1 0 1, first digit is the queue number and preceding 0 and 1 are cos values reserved for this queue similarly queue 2 3 4 are configured, queue 4 is the main queue for which cos value 5 is reserved, IP phone marks all its traffic with cos value 5

#priority-queue out

very important command this sets queue 4 to be prioritized in case of bottleneck, PQ traffic is out first.

#mls qos trust device cisco-phone
#mls cos trust cos

trust the cos vlaue only if cisco IP phone is attached, which is not good if you have phones from other vendors,switches utilize CDP to detect if their is a cisco IP phone attached.

#switchport voice vlan 100
#switchport access vlan 10

#switchport priority extend cos 0

Mark any packet from PC with cos 0

#mls qos map cos-dscp 0 8 16 24 34 46 48 56

Switch will mark the DSCP of packets according to the above map, if a layer 3 device encounters the packet and is taking decisions based on layer 3 DSCP markings. the values are mapped against 0 1 2 3 4 5 6 7 cos markings.

#mls qos bandwidth 10 20 70 0(0 or 1)

Sets the bandwidth for each queue, remember queue 4 is PQ so it will be serviced first and prioritized so you can set a 0 or 1 for this queue,0 preferable.

Configuring Cisco Extension Mobility in CUCM 7

2010-02-06T22:19:00.001-08:00

Configuration Checklist for Cisco Extension Mobility

https://[CUCM_IP]/Help/en_US/ccm/wwhelp/wwhimpl/common/html/frameset.htm

Perform the procedures in the order shown in Table 8-1 to configure Cisco Extension Mobility.

Summary steps in Table 8-1 point out the major tasks that are required to configure Cisco Extension Mobility in Cisco Unified Communications Manager Administration. For a complete set of instructions, be sure to follow the procedure that is listed in the Related Procedures and Topics.

Table 8-1 Configuration Checklist for Cisco Extension Mobility
	Configuration Steps	Related Procedures and Topics
Step 1:	Using Cisco Unified Serviceability, choose Tools > Service Activation to activate the Cisco Extension Mobility service. Note : To disable the extension mobility service on any node, you must first deactivate the service for that node in Service Activation. Note : When a change in activation or deactivation of the Cisco Extension Mobility service occurs, on any node, the database tables get updated with information that is required to build the service URLs. The database tables also get updated when the extension mobility service parameters get modified. The EMApp service handles the change notification.	For information on service activation, refer to the Cisco Unified Serviceability Administration Guide.
Step 2:	Create the Cisco Extension Mobility Service. Summary steps include Choose Device > Device Settings > Phone Services. Enter the service name (such as, Extension Mobility Service or EM). Enter the following URL: http://:8080/emapp/ EMAppServlet?device=#DEVICENAME# Note : If you should enter the URL incorrectly and subscribe the wrong service to the phones, you can correct the URL, save it, and press Update Subscriptions or correct the URL and resubscribe each phone to which the wrong service was subscribed. Select values for Service Category and Service Type. Enter a value for Service Vendor (Java MIDlet services only). (wrong). Select XML. Click Save. Enable Check Box(Must) Note : For Java MIDlet services, the service name and service vendor must exactly match the values that are defined in the Java Application Descriptor (JAD) file.	Adding the Cisco Extension Mobility Service.
Step 3:	Configure administration parameters.	Setting the Service Parameters
Step 4:	Create a default device profile for each phone type that you want to support Cisco Extension Mobility.	Creating a Default Device Profile for Each Cisco Unified IP Phone Type
Step 5:	Create the user device profile for a user. Summary steps include Choose Device > Device Settings >Device Profile and click Add New. Enter the Device Type. Enter the Device Profile Name, choose the phone button template, and click Save. Enter the directory numbers (DNs) and required information and click Save. Repeat for all DNs. To enable intercom lines for this device profile, configure intercom directory numbers (DNs) for this device profile. You configure an intercom DN in the Intercom Directory Number Configuration window, which you can also access by choosing Call Routing > Intercom > Intercom Directory Number. You must designate a Default Activated Device in the Intercom Directory Number Settings pane for an intercom DN to be active.	Creating the Device Profile for a User Intercom Directory Number Configuration, Cisco Unified Communications Manager Administration Guide
Step 6:	Associate a user device profile to a user. Summary steps include Choose User Management > End User and click Add New; enter user information. In Available Profiles, choose the service that you created in Step 2 and click the down arrow; this places the service that you chose in the Controlled Profiles box. Click Save.	Associating a User Device Profile to a User
Step 7:	Configure and subscribe Cisco Unified IP Phone and user device profile to Cisco Extension Mobility. Summary steps include Subscribe the phone and the user device profile to Cisco Extension Mobility. Choose Device > Phone and click Add New. On the Phone Configuration window, in Extension Information, check Enable Extension Mobility. In the Log Out Profile drop-down list box, choose Use Current Device Settings or a specific configured profile and click Save. To subscribe Cisco Extension Mobility to the Cisco Unified IP Phone, go to the Related Links drop-down list box in the upper, right corner of the window and choose Subscribe/Unsubscribe Services; then, click Go.	Cisco Unified IP Phone Configuration, Cisco Unified Communications Manager Administration Guide Subscribing Cisco Unified IP Phones to Cisco Extension Mobility Finding an Actively Logged-In Device, Cisco Unified Communications Manager Administration Guide

No magic file found in flash -- Booting in ROMMON mode

2010-02-06T22:16:00.000-08:00

If you have a router that goes directly in ROMMON mode and is returned with an error "No magic file found in flash"

Couple of solutions,

If you get a message saying "no magic number found" then chances are your EEPROM has gotten corrupted. You probably will have to replace the box or call Cisco TAC. This is from Cisco's CCO:

"No magic number found in RP1 EEPROM
Explanation The structure containing the system MAC address needed by the OIR facility cannot be found in the RP EEPROM. The RP must be returned for reprogramming.

Recommended Action Return the RP for reprogramming and call your technical support representative for assistance. "

You can try the following methods to recover your box.

(1)Check the confreg value and make sure it correct.
show config
Configuration register is 0x2102.

(2)Try booting from ROMMON mode only
u can try following commands
IP_ADDRESS=1.1.1.1
IP_SUBNET_MASK=255.0.0.0
GATWAY=1.1.1.2 (UR MACHINES IP ADDRESS)
TFTP_SERVER=1.1.1.2
TFTP_FILE= bootable image file
tftpdnld

(3) XModem
It can be done using Xmodem through the console connection. It takes a LONG time compared to other methods, but you can speed it up a little bit by changing the baud rate on the console from 9600 to 19200 or whatever is the fastest. This can be done in ROMMON. Don't forget to also change the baud on your serial connection on your laptop. Some of the particulars of how to do this depend on what program you use--hyperterm, teraterm, etc.

DHCP config with MS loopback adapter

2010-01-21T13:13:00.000-08:00

Here is the attached snapshot and config of my dhcp on 3725 router to get the desired result. Yes I m excited!

ip dhcp pool DATA
network 172.16.2.0 255.255.255.0
default-router 172.16.2.1
dns-server 4.2.2.2
!
!
!
interface FastEthernet0/0
ip address 172.16.2.1 255.255.255.0
duplex auto

Configuring Inter VLAN routing and DHCP-Scope-VLAN Bindings

2010-01-20T10:05:00.000-08:00

Hats off to Taha for digging it to the level it demanded, this exercise has polished DHCP and inter vlan routing issues. the details of the config are as follows

Replace the 3550 with 3725 hooked with NM-16-ESW, yep im speaking the GNS-3 language, the IP addressing is different from the above image but topology remains the same, the configs are follows.

Layer3_Switch Config

!---ENABLING IP ROUTING

conft# ip routing

!---INTERFACE TO DHCP ROUTER

conft# interface fa1/1
conft# no switchport
conft# ip address 200.1.1.1 255.255.255.0
conft# no shutdown

!---CREATING DATA AND VOICE VLANS

conft# vlan 10
conft# name VOICE
conft# vlan 10
conft# name DATA

!---CREATING SVIs FOR DATA AND VOICE VLANS

conft# interface vlan 10
conft# ip address 172.16.1.1 255.255.255.0
ADDING AN IP HELPER ADDRESS TO DHCP SERVER TO GET AN IP THROUGH VOICE SCOPE
conft# ip helper-address 200.1.1.2

conft# no shutdown

conft# interface vlan 20
conft# ip address 172.16.2.1 255.255.255.0
ADDING AN IP HELPER ADDRESS TO DHCP SERVER TO GET AN IP THROUGH DATA SCOPE
conft# ip-helper address 200.1.1.2
conft# no shutdown

!---INTERFACE TO PC AND IP SOFT/PHONE

conft# interface fa1/10
conft# switchport access vlan 20
conft# switchport voice vlan 10
conft# no shutdown

!---CREATING A DEFAULT ROUTE

------------------------------------------------------------

DHCP Router Config

conft# interface fa0/0

conft# ip address 200.1.1.2 255.255.255.0
conft# no shutdown

(config)# ip dhcp excluded-address 172.16.1.1 172.16.1.9
(config)# ip dhcp excluded-address 172.16.2.1 172.16.2.9

(config)# ip dhcp pool DATA
(dhcp-config)# network 172.16.2.0 255.255.255.0
(dhcp-config)# default-router 172.16.2.1
(dhcp-config)# dns-server 4.2.2.2
(dhcp-config)# exit

(config)# ip dhcp pool VOICE
(dhcp-config)# network 172.16.1.0 255.255.255.0
(dhcp-config)# default-router 172.16.1.1
(dhcp-config)# option 150 ip 172.16.1.1
(dhcp-config)# exit

(config)# ip route 172.16.1.0 255.255.255.0 200.1.1.1
(config)# ip route 172.16.2.0 255.255.255.0 200.1.1.1

very helpful reference document,

http://www.cisco.com/en/US/tech/tk389/tk815/technologies_configuration_example09186a008019e74e.shtml

Voice Lab Setup 17-1-09

2010-01-17T21:32:00.000-08:00

I have started setting up my home voice lab with initial infrastructure using 3725 routers at HQ, BR1 and BR2. I have added wic-2T and nm-16esw cards in each router. The initial step include the frame-relay setup among above 3 routers using frame relay switch. We can ping each HQ > BR1 and vice versa and also From HQ > BR2 and vice versa.

The config snap and topology snap is attached for your review.

Next steps would be adding HQ to local LAN, configuring vlans, dhcp server and ospf.

MCSE log

2010-01-12T23:47:00.001-08:00

Classes of IP addresses,

Class A : 1-126 : 1.0.0.1 to 126.255.255.254
Class B : 128-191 : 128.1.0.1 to 191.255.255.254
Class C : 192-223 : 192.0.1.1 to 223.255.254.254
Class D : 224-239 : 224.0.0.0 to 239.255.255.255
Class E : 240-254 : 240.0.0.0 to 254.255.255.254

pecial address ranges

Some addresses are reserved for special uses (RFC 3330).^[2]

Address range	CIDR Equivalent	Purpose	RFC	Class	Total # of addresses
`0.0.0.0 - 0.255.255.255`	0.0.0.0/8	Zero Addresses	RFC 1700	A	16,777,216
`10.0.0.0 - 10.255.255.255`	10.0.0.0/8	Private IP addresses	RFC 1918	A	16,777,216
`127.0.0.0 - 127.255.255.255`	127.0.0.0/8	Localhost Loopback Address	RFC 1700	A	16,777,216
`169.254.0.0 - 169.254.255.255`	169.254.0.0/16	Zeroconf / APIPA	RFC 3330	B	65,536
`172.16.0.0 - 172.31.255.255`	172.16.0.0/12	Private IP addresses	RFC 1918	B	1,048,576
`192.0.2.0 - 192.0.2.255`	192.0.2.0/24	Documentation and Examples	RFC 3330	C	256
`192.88.99.0 - 192.88.99.255`	192.88.99.0/24	IPv6 to IPv4 relay Anycast	RFC 3068	C	256
`192.168.0.0 - 192.168.255.255`	192.168.0.0/16	Private IP addresses	RFC 1918	C	65,536
`198.18.0.0 - 198.19.255.255`	198.18.0.0/15	Network Device Benchmark	RFC 2544	C	131,072
`224.0.0.0 - 239.255.255.255`	224.0.0.0/4	Multicast	RFC 3171	D	268,435,456
`240.0.0.0 - 255.255.255.255`	240.0.0.0/4	Reserved^[3]^,^[4]^,^[5]	RFC 1166	E	268,435,456

[edit] See also

Configuring IP Netflow in Cisco 3725

2010-01-01T22:33:00.000-08:00

Configuring IP Netflow in Cisco 3725

Disclaimer: Credit to Josh (Head Geek) www.solarwinds.com

PoE and PoE+(802.3at)

2009-12-29T21:40:00.000-08:00

Since the original introduction of PoE, the IEEE has initiated a new project called 802.3at which is commonly referred to as PoE+. This project enhances PoE in a couple of very important ways. First, it provides up to 30W of power to a Powered Device (PD), 25.5 watts to the device and 4.5 for line loss, and allows this power to also run on cabling designed for 1000BASE-T. Secondly,
it provides a new mechanism for communicating power capability and requirements using the 802.1ab Link Layer Discovery Protocol (LLDP). This protocol addition allows PoE+ switches to deliver power more efficiently and thereby provide power to more devices for a given power supply capacity. The new standard is going to be a superset of the 802.3af because it provides all
the same functionality, and more. The table below shows the capabilities of 802.3af versus 802.3at.

In order for 802.3at to provide higher power, Class D (Cat5e) or better cables are required. 802.3at also increases the minimum output voltage of the Power Source Equipment (PSE) from 44 volts to 50 volts. For this reason, you may note that ProCurve PoE+ devices use a 54 volt power supply.

Note:
The detection and classification functions ensure that if two PoE sources are attached together, power will not be improperly applied.
Here are some reasons why you might want to do this:

■ Simplifies installation and saves space - only one set of wires to bring to your appliance.
■ Saves time and money - there is no need to pay for additional electrical power runs or to delay your installation schedule to make them.
■ Minimal disruption to the workplace - the appliance can be easily moved, to wherever you can lay a LAN cable.
■ Safer - no AC voltages need to be added for additional network devices.
■ As well as the data transfer to and from the appliance, you can use SNMP network management infrastructure to monitor and control the appliances.
■ Appliances can be shut down or reset remotely - no need for a reset button or power switch.
■ When implementing wireless LAN systems it simplifies the radio frequency (RF) survey task, as the access point can easily be moved and wired in.

Power Through the Cable:

A standard CAT5 Ethernet cable has four twisted pairs. Only two of these pairs are used for 10Base-T and 100Base-TX data; all four are used for 1000Base-T data. The specification allows two options for using these cables for power:
■ The spare pairs are used. The pair on pins 4 and 5 are connected together and form the positive supply, and the pair on pins 7 and 8 are connected and form the negative supply.
■ The data pairs are used. Since Ethernet pairs are transformer coupled at each end, it is possible to apply DC power to the center tap of the isolation transformer without upsetting the data transfer. In this mode of operation the pair on pins 1 and 2 and the pair on pins 3 and 6 can be of either polarity.

The 802.3af standard does not allow both pairs (spare and data) to be used - a choice must be made. The Power Sourcing Equipment (PSE) applies power to either set of wires. HP ProCurve Networking switches, as a PSE, supply PoE power over the “data pair” or, pins 1 and 2, and the pair on pins 3 and 6. The Powered Device (PD) must be able to accept power from both options
because mid-span equipment must (according to the specification) supply power over the “spare pair” or pins 4 and 5, and the pair on pins 7 and 8.

An obvious requirement of the specification is to prevent damage to existing Ethernet equipment. A discovery process, run from the PSE, examines the Ethernet cables, looking for devices that comply with the specification. It does this by applying a small current-limited voltage to the cable and checks for the presence of a 25k ohm resistor in the remote device. Only if the resistor is present, will the full wattage be applied, but this is still current-limited to
prevent damage to cables and equipment in fault conditions.Once discovered, a different voltage is applied, and based upon the current drawn, the class of device can be determined. This indicates how much power is to be drawn. The 802.3at standard provides both a physical classification and a logical classification, which is even more precise. The PD must continue to draw a minimum current. If it does not (for example, when the device is unplugged) then the PSE removes the power and the discovery process begins again.

General Considerations
The following is an example list of considerations during the planning phase no matter which series of switches are being installed:
■ How many devices need PoE power?
■ What devices will need PoE power?
■ How much power will each device require, in watts?
■ What is the total of all their wattages?
■ Will the devices be connected to a 2910al, 3500yl, 5400 or to a 8200zl
switch?
■ How many ports are needed?
■ How many ports are available?
■ Are the devices to be powered by PoE power supported?

Disclaimer: http://cdn.procurve.com/training/Manuals/PoEPlannngGuide-Oct2009-59918574.pdf

iACLs; A Service Providers Best Practice on your LAN

2009-12-17T21:20:00.000-08:00

When I first started working on Cisco gear back in the early 18th century, ACLs were one the the biggest deployment problems I ran into on a day to day basis. On my first day of being introduced to ACL's was also my first day of introducing our user base to self inflicted Goober Admin Denial of Service attacks (GADOS).... Oh sure they made sense on the various certification exams and talking about them with other geeks over a Bawls Cola at Star Trek conventions. Hey it's just basic boolean logic right? If this variable AND that condition AND this direction MATCH=1 please proceed with instruction, if not drop into the bit bucket. And no I never fell for the old noob; "Time to empty the bit bucket" trick...more then once. But something happened between paper and practice that made me loathe ACL's more then a middle seat and vegetarian airline meal. Is it just me or do vegetarians have the worst farts ever?

anyway...

Any field engineer worth their salt knows that you have to know ACLs like you know where all the speed traps are on your way to work. It is true that you will certainly use them often but ACL theory enables a lot of other features like Flexible Packet Matching, QoS, MCQ, etc... As Yoda would say, Know them you must yes...hmmmm" I really learned ACL practical implementation by fire as a consultant for a major ISP. We used ACL's to the most minute level. As the security threats changed, large hard to follow ACL's had to change. They were eating up too much router resources, folks were afraid to edit them due to a possible outage and staff turnover not only meant the loss of a team member but a loss of the verbal history to understand why many configs were done they way they were.

The iACL came out of that casting forge. ACLs as a feature will not change because of their boolean logic they will only keep expanding to include more AND conditions and some OR conditions. And lets face it, the security threat is not going to get easier only more detailed. A new way of using ACLs was needed at the ISP level. iACLs are not a new feature or a product from Apple they are a new method to use ACL's at your Internet Edge. The "i" in iACL stands for Infrastructure. These entries are very detailed and very powerful. I was going to put in some pointless quote about power and the darkside of the Force but I have already quoted Star Wars once in this blog and that is the legal limit. So let's build out an iACL for my network here in the CodeCave(tm). My network internal address in 172.16.1.0 which is the same I am using on the Internet which is of course illegal which means I am of course lying for simplicity sakes!

Step 00x01: iACLs are as personal to your network as your own underwear is to you. With that is mind, most of us have a good idea what traffic is on the network and if not if you have a feature like NBAR and/or NetFlow this will help shape your initial ACL. To get started, lets build out a Discovery ACL to see what traffic we actually have. I would start out with this one:

access-list 222 permit tcp any any eq 22 log
access-list 222 permit udp any any eq syslog log
access-list 222 permit udp any any eq ntp log
access-list 222 permit ospf any any log
access-list 222 permit icmp any any log
access-list 222 permit tcp any any eq tacacs log
access-list 222 permit ip any any log

Place this ACL on the inbound interface. Remember this eats up router resources so leave this on only as long as you need it to get a good picture of your network. I normally do 3-5 days, however, your mileage may vary! Many things depend on this, number of connections, router size, etc.

Step 00x02:Now I monitor my logs to see what is hitting where. I can do this with the command:

TechWiseTVRTR#sh access-list 222

10 permit tcp any any log (55 matches)
20 permit udp any any eq syslog log (8 matches
..... you get the idea here.....but one more just for fun
70 permit ip any any log (73 matches)

What I am looking for is a small number of hits on my IP ANY ANY statement. A large number means I have stuff not being classified and I need to redefine my Discovery ACL just a bit or dig back into NBAR/NetFlow to see what is flowing thru this network and try again. Remove the Discovery ACL when I am finished.

Step 00x03:Test time! Time for the rubber to hit the road! This is the final step before we create the iACL. I will create a phone call ACL that is very specific. I know this ACL works if the phone in the support center does not ring...

access-list 222 permit ospf host 172.16.1.1 host 224.0.0.5
access-list 222 permit ospf host 172.16.1.1 host 224.0.0.6
access-list 222 permit icmp host 172.16.1.1 192.168.0.0 0.0.255.255
access-list 222 permit tcp host 172.16.1.1 eq 22 192.168.0.0 0.0.255.255
..... You get the idea...OK one more, but this is the last time
access-list 222 permit ip any any log

I put the IP ANY ANY at the end with a log statement to still monitor hits. Run this for a week or so then remove it and proceed to the iACL!!!

Step 00x04: This is it. All the training in a Russian barn in Winter, running up the snow covered hill...Oh sorry, I really need to turn the TV off. Built out the iACL. An iACL has four modules that make it up:

- Deny Special Use and Fragments
- Explicit Permit
- Explicit Deny to Protect the Infrastructure
- Expect Permit for Transit Traffic

Before we get started building out our iACL remember the two most coveted rules in network engineering:

- Never have a end user troubleshoot a network
- Always build out your networks for the next person that follows you.

PLEASE remember to comment out your ACL's, so your history does not leave when you do.

Module 01: Deny Special Use. This module of my iACL looks like this with dated comments:

!---- Module 1 iACL Dec09 Deny Special Use RFC 3330

access-list 222 deny ip host 0.0.0.0 any
access-list 222 deny ip host 127.0.0.0 0.255.255.255 any
access-list 222 deny ip host 192.0.2.0 0.0.0.255 any
access-list 222 deny ip host 224.0.0.0 31.255.255.255 any

***shortened for blog. Check out the table in RFC 3330 for more address***

!--- Module 1 Dec09 Deny RFC 1918 IP space

access-list 222 deny ip 10.0.0.0 0.255.255.255 any
access-list 222 deny ip 172.16.0.0 0.15.255.255 any
access-list 222 deny ip 192.168.0.0 0.0.255.255 any

Module Two:Explicit Permit This is where I allow only authorized external traffic to access internal devices. In this example I will allow routing protocols and SSH only. Basically, it is my control and management traffic.

!---- Module 2 iACL Dec09 Explict Permit

access-list 222 permit ospf host 172.16.1.1 host 172.16.1.2 eq ospf
access-list 222 permit ospf host 172.16.1.1 eq ospf host 172.16.1.2
access-list 222 permit ospf host ospf_neighbor host 224.0.0.5
access-list 222 permit ospf host ospf_neighbor host 224.0.0.6
access-list 222 permit tcp host 172.16.1.4 host 172.16.1.8 eq 22

Module Three: Explicit Deny to Protect the Infrastructure from external sources

!--- Module 3 iACL Dec09 Explicit Deny to Protect Infra
access-list 222 deny ip any 172.16.1.0 0.0.0.255

Module Four: Explicit Permit. This is my transit statement to let internal traffic move about.

!--- Module 4 iACL Dec09 Explict Permit for LAN traffic

access-list 222 permit ip any any

Now you may have noticed that I do not have the source address in many iACL entries. This is becuse I have IP Source Guard enabled at the edge ports and I am enforcing this validation there. This keeps my iACLs smaller and router processing more streamlined. More info in iACL can be found at http://www.cisco.com/go/safe This iACL example is for an Internet Edge router. You can also have a smaller iACL for the LAN as well. Give iACLs a try in your shake and bake lab. They may look a little tough, but it's kinda like eating crap food, breaking it down to smaller parts makes it much easier and that's the idea of modules!

Jimmy Ray Purser

Trivia File Transfer Protocol
Astronomers have long used the Light Year as a standard of measurement. Not to be left out Nuclear Physicists need a measurement standard as well but for much smaller distances. They use the beard second. Which is basically how fast an average (define that I dare you) Nuclear Physicists beard grows in one second, around 5 nanometers. Type in beard-second in Google to see it covert an inch into a beard second to see how small of a measure this really is.

Disclaimer: The article is originally written By JimmyRay, www.networkworld.com

Audio Codec Negotation

2009-12-17T21:18:00.000-08:00

Cisco routers acting as voice gateways perform an important job in Unified Communications (UC) deployments. Digital signal processors (DSP) in voice gateways translate voice over IP real-time protocol (RTP) media to time division multiplexing (TDM) required for traditional telephony interoperability. A variety of audio codecs that have different audio quality and bandwidth requirements are used on the voice over IP (VoIP) call leg that determine call quality. Voip dial peers in Cisco routers default to the compressed G.729 audio codec, but codecs can be negotiated in SIP and H.323 gateways. MGCP gateways do not support any codec negotiation because Cisco Unified Communications Manager (CUCM) dictates the codec to the calling party as a result of the region configuration.

H.323 uses the H.245 protocol to provide audio, video, and data media negotiation. SIP leverages session description protocol (SDP) to provide the same information. Regardless of the protocol utilized, the configuration is the same in Cisco IOS of the gateway router. The router 1 voice class configuration below is applied to dial peer 900 with the will send out a listing of prioritized codec capabilities to 10.1.1.1.

ROUTER1:

Voice class codec 90
Codec preference 1 g729a
Codec preference 2 ilbc
Codec preference 3 g722
Codec preference 4 g711ulaw
!
Dial-peer voice 900 voip
Destination-pattern 15…
Voice-class codec 90
Session target ipv4:10.1.1.1

The receiving device will make the final codec determination via the local voice class codec negotiation. If a call is routed from router 1 to router 2, the voice class below will result in an audio codec of g711ulaw because both routers support the codec and it is the called party’s preferred audio codec.

ROUTER2:

Voice class codec 914
Codec preference 1 g711ulaw
Codec preference 2 ilbc
Codec preference 3 g722
Codec preference 4 g729a
!
Dial-peer voice 500 voip
Incoming called-number 15…
Voice-class codec 914

The following debugs can be used to verify the media negotiation in H.323 and SIP respectively. Update your resume before running debugs in production environments.

Debug h245 asn1
Debug ccsip messages

Disclaimer: the article is originally written By Dennis Hartmann, www.networkworld.com

10GE and Network Oversubscription Ratios

2009-12-17T21:16:00.000-08:00

Lately I have seen many data center designs that contain 10 Gigabit Ethernet links at the access, distribution and the core hierarchy layers. Traditionally, the bandwidth increases as you reach the core of the network. Historically, networks were like trees. The access network "leaves" are smaller, the distribution network "branches" are a little bigger, and the core network "trunk" is thick. However, due to the prolific use of 10 GE interfaces traditional network design oversubscription ratios are not achievable.

When constructing a multi-tiered network design it is important to consider the bandwidth oversubscription ratios at every layer of the Ethernet switching hierarchy. The idea is that the upstream bandwidth at each layer of the hierarchy must provide adequate bandwidth for those downstream devices. However, statistics drive the ratios that make the total size of the uplink not need to sum to the total amount of the downstream links. This "oversubscription" ratio of downlinks to uplinks is what needs to be closely monitored so that at places in the network bottlenecks do not form that could be difficult to detect and provide poor network connectivity for downstream devices.

Common access-downlink to access-uplink ratios are 20:1 and distribution-downlinks to distribution-uplink ratios are 4:1. Below is a figure that illustrates this concept. This diagram below shows a 20:1 ratio between access-ports on an Intermediate Distribution Frame (IDF) switch and the uplinks to the distribution switch as well as a 4:1 ratio of distribution switch downlinks to its core uplinks. Traditionally, single Gigabit Ethernet links are used to connect servers, the uplinks are 10GE links, and the core is connected with four 10GE links.

A similar diagram can be found in the Cisco Enterprise QoS Solution Reference Network Design Guide (SRND) version 3.3.

Many newer servers and blade centers are coming with 10GE interfaces. The links between core devices are also using 10GE interfaces. Now we have a design where the leaves are as thick as the trunk of the tree. Therefore, 10GE is changing oversubscription ratios commonly used in network designs.

For example, if an IDF has 240 ports (5 switch stacks of 48 port 10/100/1000Mbps switches) then the total downstream bandwidth is 240Gbps. Therefore, the uplink bandwidth should be 1:20 of 240Gbps or 12Gbps. Those uplinks will probably be a pair of 10GE links. Then consider a set of distribution switches that support only four of those IDFs. Therefore, the total distribution layer downstream bandwidth would be 960Gbps. The uplink bandwidth should be 1:4 of 960Gbps or 240Gbps. However, since we lack the ability to deploy that amount of bandwidth then we are faced with probably using a set of four 10GE links from each distribution switch to each of the pair of core switches.

The second example is when we have servers with 10GE links. Let's say a Nexus switch has 32 10GE links to servers, clusters, and blade centers in the data center. The 20:1 rule would indicate that there would be 16Gbps of uplink bandwidth. That could be satisfied with a couple of 10GE uplinks to the distribution switches. Those distribution switches could only have a couple of these IDF switches downstream in order to require only a few 10GE uplinks to the core switches.

The distribution layer is getting squeezed out with the extensive use of 10GE interfaces within data centers and more organizations may be looking at a 2-tier model rather than the traditional 3-tier model. In the two-tier model, the only ratio used is the 20:1 from the access downlinks to the access uplinks to the core.

40GE and 100GE on the Horizon:

This oversubscription ratio problem won't remain like this for long. We can see already see 40 Gbps Ethernet and 100 Gbps Ethernet on the horizon. Earlier this year the NYSE announced plans to deploy 100Gbps Ethernet. Service providers like Qwest are planning early deployments of 100Gbps in their high-performance backbones. In fact, the some of the first 100Gbps links have already been sold. In my opinion, I agree with those who are proponents of skipping 40Gbps Ethernet and going straight to 100Gbps Ethernet. I also feel that 100Gbps Ethernet is going to gain wider industry adoption than OC-768. History has shown that you just can't beat Ethernet for simplicity, performance, and price.

Conclusion:

The use of 10GE interface for access, distribution, and core will cause network architectures that have leafs with the same bandwidth as the tree's trunk. In order to maintain oversubscription ratios the industry is looking toward using 100GE in the years to come. Network World published their "100G Ethernet cheat sheet" a few weeks ago. I encourage you to check out these articles and keep track of how 100Gbps Ethernet will affect how you design networks in 2010.

Scott

Disclaimer: The article is written by By Scott Hogg, www.networkworld.com

Configuring NetFlow (I love this feature)

2009-11-30T20:48:00.000-08:00

Credits to the original Author..

CONFIGURING THE ROUTER

First on Cisco box enable Cisco Express Forwarding:

router(config)# ip cef
router(config)# ip cef distributed

and turn on flow accounting for each input interface with the interface command:

interface FastEthernet3
ip route-cache flow

interface Serial3/1
ip route-cache flow

...

Now, verify that the router (or switch) is generating flow stats. Try command 'show ip cache flow'. Note that for routers with distributed switching (GSR's, 75XX's) the RP cli will only show flows that made it up to the RP. To see flows on the individual linecards use the 'attach' or 'if-con' command and issue the 'sh ip ca fl' on each LC.

IP packet size distribution (36242M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.002 .340 .084 .021 .020 .012 .009 .009 .008 .007 .006 .007 .004 .003 .004

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.002 .004 .035 .077 .338 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes
4139 active, 61397 inactive, 712344771 added
871670181 ager polls, 0 flow alloc failures
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 1572735 0.3 58 127 21.4 27.0 14.8
TCP-FTP 6193502 1.4 24 746 35.3 3.6 9.0
TCP-FTPD 1458042 0.3 1534 833 520.9 42.4 4.2
TCP-WWW 93403998 21.7 19 633 432.9 4.9 6.3
TCP-SMTP 16123540 3.7 15 431 59.1 3.4 6.4
TCP-X 687228 0.1 238 276 38.1 20.8 14.3
TCP-BGP 1116819 0.2 3 45 0.7 5.3 16.0
TCP-NNTP 1455156 0.3 1102 176 373.4 106.1 11.9
TCP-Frag 3244 0.0 4 636 0.0 2.8 16.3
TCP-other 188162587 43.8 118 733 5204.5 11.1 6.9
UDP-DNS 38042100 8.8 3 84 27.3 3.8 16.4
UDP-NTP 18760129 4.3 1 76 5.3 1.3 16.3
UDP-TFTP 665 0.0 4 76 0.0 7.9 16.4
UDP-Frag 13111 0.0 2121 1108 6.4 366.8 13.5
UDP-other 195556237 45.5 35 343 1632.5 5.8 16.3
ICMP 149285440 34.7 2 64 72.9 0.9 16.5
IGMP 15315 0.0 167 32 0.5 1660.6 3.9
IPINIP 15112 0.0 35 52 0.1 275.3 14.2
GRE 127489 0.0 3 109 0.1 16.9 16.1
IP-other 348604 0.0 56 447 4.5 21.5 16.2
Total: 712341053 165.8 50 620 8436.8 6.2 12.2

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
AT4/0.1 128.146.225.194 AT1/0.2 128.194.203.23 06 0019 2CAF 15
AT2/0.10 129.22.250.148 AT1/0.2 129.2.226.43 06 04BA 1A20 1266
AT2/0.11 130.108.110.48 AT1/0.2 170.140.89.100 06 0923 10A3 436
AT1/0.2 170.140.89.100 AT2/0.11 130.108.110.48 06 10A3 0923 462

! Enable the exports of flows with the global commands
router(config)# ip flow-export version 5 origin-as
router(config)# ip flow-export 10.0.0.2 2000

! Create a loopback interface if one does not exist
!
router(config)# interface Loopback0
ip address 10.0.0.1 255.255.255.255

!
! Configure NetFlow export source address
!
router(config)#ip flow-export source Loopback0

If you have tcpdump installed on or near the host you're using to capture flows, the exports can be verified.

netflow:~# tcpdump -n udp port 2000
tcpdump: listening on eth0
12:11:29.953100 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:29.962551 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:29.975115 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:29.984444 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:29.993956 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.003252 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.015483 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.024852 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.034182 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.043545 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168
12:11:30.053239 10.0.0.1.1868 > 10.0.0.2.2000: udp 1168

SETTING UP NETFLOW COLLECTOR

After installation of NetFlow Collector, edit file /etc/netflow/nfc.conf In this file you can specify, NetFlow Collector Unit Id, this id must correspond with id created by NetFlow Web tool (see installation of NetFlow Web and installation of mysql database). This id is unique for one computing unit ~ one computer. In one unit can run more collectors (one collector ~ at least one netflow export source / router). Unit ID is under section [Main]. In config file there's another section [Database]. You can specify, database name (default nf), hostname (default localhost), username (default root), password, etc ... If you run all-in-one (NetFlow Collector, NetFlow Web and database in one box, you needn't modify anything in the file /etc/netflow/nfc.conf All other parameters are setup by web interface ...
Now, it is all, you can try run collector by typing

netflow:~#/etc/init.d/nfc start

Now it's good time to check syslog for any errors ...

netflow:~#less /var/log/syslog

Auto-MDIX dilemma

2009-11-25T22:18:00.000-08:00

Configuring Auto-MDIX on an Interface
"When automatic medium-dependent interface crossover (auto-MDIX) is enabled on an interface, the interface automatically detects the required cable connection type (straight through or crossover) and configures the connection appropriately. When connecting switches without the auto-MDIX feature, you must use straight-through cables to connect to devices such as servers, workstations, or routers and crossover cables to connect to other switches or repeaters. With auto-MDIX enabled, you can use either type of cable to connect to other devices, and the interface automatically corrects for any incorrect cabling. For more information about cabling requirements, see the hardware installation guide.

Auto-MDIX is enabled by default. When you enable auto-MDIX, you must also set the interface speed and duplex to auto so that the feature operates correctly. Auto-MDIX is supported on all 10/100 and 10/100/1000-Mbps interfaces and on 10/100/1000BASE-TX small form-factor pluggable (SFP)-module interfaces. It is not supported on 1000BASE-SX or -LX SFP module interfaces."

So you can use a straight through cable to connect two switches, but you then cannot explicitly set the speed and duplex.

"To be fair, I wasn’t aware of the auto-MDIX needing auto-negotiation issue, BUT whenever you are troubleshooting a problem you want to minimize any deviations from known working configurations to eliminate unnecessary variables. I think that I remember reading that auto-MDIX uses the same protocol as auto-negotiation and that’s why both need to be enabled. I’m not positive about that though."

Assume that “correct cabling” means a cross-over cable and “incorrect cabling” means a straight-through cable.

Local Side Auto-MDIX	Remote Side Auto-MDIX	With Correct Cabling	With Incorrect Cabling
On	On	Link up	Link up
On	Off	Link up	Link up
Off	On	Link up	Link up
Off	Off	Link up	Link down

You can refer to the table below, but it’s pretty easy to determine if a link will be up or not: at least one side needs to have auto-MDIX enabled along with auto-negotiation of speed and duplex, otherwise the link will be down.

sw1		sw2
MDIX	Speed/Duplex	MDIX	Speed/Duplex	Link Status
on	auto	on	auto	up
on	auto	on	hard-set	up
on	auto	off	auto	up
on	auto	off	hard-set	up
on	hard-set	on	auto	up
on	hard-set	on	hard-set	down
on	hard-set	off	auto	down
on	hard-set	off	hard-set	down
off	auto	on	auto	up
off	auto	on	hard-set	down
off	auto	off	auto	down
off	auto	off	hard-set	down
off	hard-set	on	auto	up
off	hard-set	on	hard-set	down
off	hard-set	off	auto	up
off	hard-set	off	hard-set	down

This makes sense because you need at least one side to be able to logically switch the pinouts of a straight-through cable to emulate a cross-over cable. Hard-setting the speed or duplex disables the auto-negotiation protocol (which auto-MDIX must utilize as well) which effectively disables auto-MDIX:

Note: The only command that I know of that will show the auto-MDIX state of an interface (other than looking at the running-configuration of the interface) is the rather verbose “show controllers ethernet-controller fax/x phy | include MDIX” command.

Note: The default setting for switch ports is to have auto-MDIX enabled. This is a pretty recent change though. IOS versions prior to 12.2(20)SE will use the default of “no mdix auto”.

“mdix auto” is the default, so it does not show in the running-configuration:
sw2(config)#do sh run int fa0/32
Building configuration…
Current configuration : 34 bytes
!
interface FastEthernet0/32
end

We can verify that auto-MDIX is on for this interface:
sw2(config)#do sh controll eth fa0/32 phy | i MD
Auto-MDIX : On [AdminState=1 Flags=0x00052248]

Let’s hard-set the speed and see what happens to auto-MDIX:
sw2(config)#int fa0/32
sw2(config-if)#speed 100
sw2(config-if)#do sh control eth fa0/32 phy | i MD
Auto-MDIX : Off [AdminState=1 Flags=0x00010A48]

Notice that our configuration does not state that auto-MDIX has been disabled:
sw2(config-if)#do sh run int fa0/32
Building configuration…

Current configuration : 45 bytes
!
interface FastEthernet0/32
speed 100
end

This verifies that hard-setting the speed and/or duplex turns off auto-MDIX for the interface.

Note: I did test to see if DTP was effected by auto-MDIX. It was not. As long as the link was up, DTP could work it’s trunking magic.

So the long and the short of it is: you can use straight-through cables to connect two Cisco switches as long as you are willing to sacrifice the ability to hard-set the speed and/or duplex on both sides of the link.

Surprisingly i tested above commands on a 2950 and a 3550-SMI switches, i could not get any info regarding auto-mdix.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_see/configuration/guide/swint.html

Polycom soundstation2 and Nortel Meridien option 11c

2009-11-25T21:50:00.000-08:00

Apparently when Nortel Meridien 11c PBX is hooked with one of the new DLC cards i.e, 16 port or 48 port,the soundstation2
seems to hang up when initializing, there are couple of solutions to this issue;

(1)Download the latest firmware, this step is mandatory, the old firmware has some issues with latest DLC Crads and sound station2 integration.

(2)As per Polycom's recommendations use M2616 Configuration for soundstation2.

(3)Polycom's documentation:
"SoundStation2 Direct Connect is compatible with any digital voice port on NORTEL® Meridian®, Meridian 1 (option 11 to 81), SL-1, or SL-100 PBX with the exception of those supporting MBS (CENTREX®) phone sets. In addition to the basic product functions, it supports two special functions - Conference and Transfer - in the same manner as the default M2616 Model 20, using key number position 3 for Conference and key number position 6 for Transfer. Contact your PBX Administrator to confirm that the Conference and Transfer functions at the port are assigned to these key number positions."

(4)A forum stated the same issue, one of the guy responded'
"I have been in touch with Polycom support (an on-line support system, no TELEPHONE support - how ironic). They have stated that "The SoundStation2 Nortel will emulate a M2009 set if there is no digital telephone set attached to the interface."

(5)You can try this,
"Carl, do you have a 2616 to test with? Start with the basics. See if the port will work with a 2616, if you have one. If you don't have a 2616, plug in a 3903 or 3904 and you should still be able to get dial-tone."

I read on another forum, that there are dip switches you need to set, in order for the unit to work correctly (Not specific to your issue, but I would set them ahead of time).

The separate box where all the cables and power goes turn it upside down, by the Polycom logo on the serial number sticker there will be a tiny square overlay sticker, peel it back and it will reveal 3 jumper switches, from memory turn number 3 off
1 = on
2 = on
3 = off

you can try this if you want to,

Configure your TN 6-12 as a TYPE 3904 (instead of 2616 as they suggest in the user guide), then use the supplied connectors and an M3904 set. Reason I would try this is that as per above printed info, they want you to use an appropriate Nortel phone in line with the unit. Since you don't have a 2616 phone, may be you can get away with M3904. That way the PBX will at least have the correct phone type matched to the TN, and I doubt that the Soundstation will know the difference, as long as your conf / trn keys are as per user guide.

Second thing to try is to configure your TN 6-12 as an TYPE 2009 (this is before my time, so not sure that you can just enter this type), then connect the sound station directly to the voice point, meaning you are then using their suggested method.

References, credit to original authors

Ploycom KB

http://www.polycom.com/support/voice/soundstation/soundstation2.html

PBX-Info

http://www.pbxinfo.com/forums/showthread.php?t=35075

Nortel KB

http://support.nortel.com/go/main.jsp?cscat=DOCUMENTATION&poid=8310&catOID=-9602&viewOptSelect=&viewOpt1=&viewOpt2=DEFAULT&searchText=&searchType=fulltext&x=43&y=3

Difference Between HWIC-2FE and HWIC-4ESW

2009-10-26T22:24:00.000-07:00

Cisco EtherSwitch 4- and 9-Port High-Speed WAN Interface Cards

Q. Can the individual ports be configured as routed ports?

A. No, the Cisco EtherSwitch HWICs do not support routed ports. This means you cannot assign an IP address directly to the interface and make it a Layer 3 interface.

Q. Can I assign each switch port to a unique VLAN? If so, are there any limitations?

A. Each switch port can be assigned to its own VLAN, effectively providing four additional routed ports. However, there are serious performance and feature limitations to doing this. The VLAN interfaces are truly Layer 3 switching interfaces and are treated uniquely among interface types on the router. Many features are not supported or tested on these interfaces, including Point-to-Point Protocol over Ethernet (PPPOE) termination, Layer 2 Tunneling Protocol Version 3 (L2TPv3) termination, MAC address assignment, Layer 3 QoS, and others. You should carefully test any desired feature and solution prior to deploying it.

http://www.cisco.com/en/US/prod/collateral/routers/ps5853/prod_qas0900aecd8016c026_ps5854_Products_Q_and_A_Item.html

Cisco 1- and 2-port Fast Ethernet High-Speed

Q. Can these interfaces be used as switch ports?

A. No, these are native Layer 3 interfaces, designed for routing. They can be configured to bridge using the router CPU. There is no switching application-specific integrated circuit (ASIC), nor are switching features supported.

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/prod_qas0900aecd80582015.html

Marking using NBAR

2009-04-21T05:28:00.000-07:00

Command List

Use the following commands to complete this exercise:

Command	Description
no service-policy {input \| output} policy-map-name	Removes a service policy from an input or output interface.
show ip cef	Displays the state of Cisco Express Forwarding (CEF).
ip nbar protocol-discovery	Configures NBAR to discover traffic for all protocols known to NBAR on a particular interface.
clear ip nbar protocol-discovery	Clears NBAR protocol discovery statistics.
show ip nbar protocol-discovery [interface interface-spec]	Displays the statistics gathered by the NBAR protocol discovery feature.
ip access-list {standard \| extended} access-list-name	Defines an IP access list by name.
permit tcp source source-wildcard destination destination-wildcard [operator [port]]	Sets conditions to allow a TCP packet to pass a named IP access list.
permit udp source source-wildcard destination destination-wildcard [operator [port]]	Sets conditions to allow a UDP packet to pass a named IP access list.
class-map class-map-name	Creates a class map to be used for matching packets to a specified class.
match protocol protocol-name	Configures the match criteria for a class map on the basis of the specified protocol.
match access-group {access-group \| name access-group-name}	Configures the match criteria for a class map on the basis of the specified access list.
policy-map policy-map-name	Creates or modifies a policy map that can be attached to one or more interfaces.
class {class-name \| class-default}	Specifies the name of the class whose policy you want to create or change or to specify the default class.
set dscp dscp-value	Marks a packet by setting the differentiated services code point (DSCP).
service-policy {input \| output} policy-map-name	Attaches a policy map to an input, or an output interface.
show class-map class-map-name	Displays all class maps and their matching criteria.
show policy-map policy-map	Displays the configuration of all classes for a specified service policy map or all classes for all existing policy maps.
show policy-map interface interface-name [input \| output] [class class-map-name]	Displays the packet statistics of all classes that are configured for all service policies on the specified interface.

Table 1: Configuration and monitoring commands used in this Lab exercise

Complete Solution;

ip access-list extended VoIP-RTCP
permit udp any any range 16384 32767
!
ip access-list extended Voice-Control
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
!
class-map match-any real-time

match protocol rtp
match protocol icmp
match access-group name VoIP-RTCP
class-map match-any mission-critical
match protocol sqlnet
match access-group name Voice-Control
class-map match-all interactive
match protocol citrix
class-map match-all bulk
match protocol ftp
class-map match-any scavenger
match protocol kazaa2
match protocol napster
!
policy-map mark-nbar
class real-time
set dscp ef
class mission-critical
set dscp af31
class interactive
set dscp af21
class bulk
set dscp af11
class scavenger
set dscp cs1
class class-default
set dscp default
!
interface fastethernet0/0
service-policy input mark-nbar

----------------------------------------------------------

Configuration 12: Configuration description
Step 18 The following commands need to be entered on R1 router.
R1#show policy-map interface fastethernet0/0
FastEthernet0/0
Service-policy input: mark-nbar
Class-map: real-time (match-any)
5 packets, 570 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol rtp
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol icmp
5 packets, 570 bytes
5 minute rate 0 bps
Match: access-group name VoIP-RTCP
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp ef
Packets marked 5
Class-map: mission-critical (match-any)
7298 packets, 770942 bytes
5 minute offered rate 27000 bps, drop rate 0 bps
Match: protocol sqlnet
6596 packets, 694955 bytes
5 minute rate 22000 bps
Match: access-group name Voice-Control
702 packets, 75987 bytes
5 minute rate 6000 bps

QOS - MQC and class Based Markings Demystified

2009-04-14T01:03:00.001-07:00

The 6-bit DSCP field (described in RFC 2474) defines the per-hop behavior (PHB). A PHB is an externally observable
forwarding behavior or QoS treatment performed by a network device such as a router or a switch.

The four different DiffServ PHBs are Best Effort (BE), Class Selector (CS), Assured Forwarding (AF), and Expedited
Forwarding (EF):

n BE is indicated when all 6 bits of the DS field are zero, and it has no specific QoS treatment.
n CS is used for backward compatibility with IP Precedence, and when using this PHB, the last 3 bits of the DSCP
field are zero.
n AF (defined in RFC 2597) specifies four different classes, along with three different drop precedences.
When using AF, the first 3 bits of the DS field define the queuing class (1 to 4), and the last 3 bits define the drop
precedence (the likelihood of the packet being dropped [1 to 3]). AF PHB names are often written in the AFxy
format, where x is the queuing class and y is the drop precedence.
n EF (RFC 3246) specifies a low delay, low jitter, and low packet-loss QoS treatment with a bandwidth guarantee.

Follow the sequence of commands mentioned above to configure class based marking of trafficStep 1 The following commands need to be entered on R1 router.

access-list 101 permit tcp any any eq ftp
access-list 101 permit tcp any any eq ftp-data

Configuration 1: Configuration description

Step 2 The following commands need to be entered on R1 router.
access-list 102 permit tcp any any eq www

Configuration 2: Configuration description

Step 3 The following commands need to be entered on R1 router.
class-map match-ftp
match access-group 101
!
class-map match-www
match access-group 102

Configuration 3:
Configuration description
Step 4 The following commands need to be entered on R1 router.
policy-map mark-apps
class match-ftp
set dscp af11

class match-www
set dscp default

Configuration 4: Configuration description

Step 5 The following commands need to be entered on R1 router.
interface fastethernet0/0
service-policy input mark-apps

Configuration 5: Configuration description

Step 6 Class FTP: matched_ 1749__ marked_ 1749__
Class WWW: matched_ 1028__ marked_ 1028__
Class class-default: matched_ 28733_

Resetting the Password on a 3560

2009-02-22T22:50:00.000-08:00

The below Method is for when password Recovery Mechanism is Enabled For other situations and scenarios see the link below.

Step 0 : Press the Mode button, and at the same time, reconnect the power cord to the switch.

You can release the Mode button a second or two after the LED above port 1 goes off. Several lines of information about the software appear along with instructions:

The system has been interrupted prior to initializing the flash file system. The following
commands will initialize the flash file system, and finish loading the operating system
software#

flash_init

load_helper

boot

Step 1 Initialize the Flash file system:

switch: flash_init

Step 2 If you had set the console port speed to anything other than 9600, it has been reset to that particular speed. Change the emulation software line speed to match that of the switch console port.

Step 3 Load any helper files:

switch: load_helper

Step 4 Display the contents of Flash memory:

switch: dir flash:

The switch file system appears:

Directory of flash:

13  drwx         192   Mar 01 1993 22:30:48  c3560-i5-mz.121.19-EA1

11  -rwx        5825   Mar 01 1993 22:31:59  config.text

18  -rwx         720   Mar 01 1993 02:21:30  vlan.dat

16128000 bytes total (10003456 bytes free)

Step 5 Rename the configuration file to config.text.old.

This file contains the password definition.

switch: rename flash:config.text flash:config.text.old

Step 6 Boot the system:

switch: boot

You are prompted to start the setup program. Enter N at the prompt:

Continue with the configuration dialog? [yes/no]: N

Step 7 At the switch prompt, enter privileged EXEC mode:

Switch> enable

Step 8 Rename the configuration file to its original name:

Switch# rename flash:config.text.old flash:config.text

Step 9 Copy the configuration file into memory:

Switch# copy flash:config.text system:running-config
Source filename [config.text]?
Destination filename [running-config]?

Press Return in response to the confirmation prompts.

The configuration file is now reloaded, and you can change the password.

Step 10 Enter global configuration mode:

Switch# configure terminal

Step 11 Change the password:

Switch (config)# enable secret password

The secret password can be from 1 to 25 alphanumeric characters, can start with a number, is case sensitive, and allows spaces but ignores leading spaces.

Step 12 Return to privileged EXEC mode:

Switch (config)# exit
Switch#

Step 13 Write the running configuration to the startup configuration file:

Switch# copy running-config startup-config


http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/
release/12.1_19_ea1/configuration/guide/swtrbl.html#wp1090048

Power and Memory Allocation errors on a 3550

2009-02-22T22:37:00.000-08:00

%SYS-2-MALLOCFAIL & %ILPOWER-3-CONTROLLER ERR

I received these two errors today on a 3550 Running CCME

--%ILPOWER-3-CONTROLLER ERR

This Error is due to power spike on an interface most probably from an IP phone, causing the power controller to go down shut and then no shut the interface. proper grounding for the IP phone.

http://supportwiki.cisco.com/ViewWiki/index.php/ILPOWER-3-CONTROLLER_ERR:_Controller_error%2C_Controller_number_(chars):_accessing_failed_error_message_on_a_Catalyst_3550_series_switch

--%SYS-2-MALLOCFAIL

The Error is due to unavailability of the free memory block, a process is trying to write data on for details see.

http://supportwiki.cisco.com/ViewWiki/index.php/The_%22SYS-2-MALLOCFAIL%22_messages_are_displayed_in_the_logs_of_Catalyst_switches

Connecting Cisco Switches to Avaya/Polycom/HP and Etc Phones

2009-01-13T20:32:00.000-08:00

Only Cisco & Mitel phones will use CDP to discover the Voice VLAN, however other methods exist to inform the IP Phones of the voice VLAN. Ericsson/Aastra, Nortel & Avaya all use DHCP they boot on the access VLAN and via DHCP options discover the Voice VLAN, they then release the IP address and restart using 802.1q tagged frames.
Although the functionality of an Access port configured like this:

CODE

switchport mode access
switchport access vlan 10
switchport voice vlan 100

is the same as a trunk configured like this

CODE

switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 10
switchport trunk allowed vlan 10,100

There are other implations of hard-coding the port as a trunk which is why I wouldn't recommend it.

I have sucessfully deployed several Nortel, Ericsson & Mitel IP Telephony systems using access ports with voice vlans.

Back to the original problem though... Are you plugging the phones directly into the switch using a fully-wired patch cable (i.e. not via the infrastructure cabling)? Are you trying to hard-code speed & duplex (don't....). Have you done any debugging?

I've always understood from Cisco that non-cisco devices should have a proper .1q trunk configured.

For example:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_example09186a0080891554.shtml

It doesn't make a huge difference, I suppose, because you end up with something similar in either case.

Like you, I have deployed Nortel, Ericsson and Siemens IP phones using my particular bias when it comes to switch configuration. :)

Not that I've often had power issues. Once I found a switch that was refusing to grant power due to being "out of memory", which was somehow caused by a damaged stackport.

LLDP - now theres a thing. Yes this should work but its only supported on the newer Catalysts (2960, 3560, 3750) and 6500's. For some reason (to sell more product...) Cisco have refused to add LLDP to the older switches. I know Nortel support LLDP as well as the newer Cisco IP Phones. Ericsson/Aastra certainly don't in the latest firmware but its supposed to be coming? Not sure about Mitel or Avaya?

I have some Polycom phones going to an Adtran T1 L3 switch (PoE, basically a Cisco!) that they say can use CDP. The phones are SPIP-500/501

I recall HP switches used CDP until firmware updates in 2005/2006.

Don't forget Cisco supports LLDP, though, if your phones support it.

Avaya does support LLDP. Avaya phones also work with either switchport voice vlan OR 802.1Q trunk ports using DHCP/Text files to configure VLAN assignment.

I have heard, If we add one by one Avaya or Nortel IP Phones to cisco switches (mostly 48 port), SOME TIMES last couple of phone finds not enough power to bootup. This usually happens when all the 48 ports are used.

Courtesy
http://www.tek-tips.com/viewthread.cfm?qid=1517008&page=1

Upgrading from 4.X to CUCM 6.0

2009-01-12T01:19:00.000-08:00

I found this brief detail from a forum regarding The upgrade process, latter i will more details. courtesy cukon.

Yes it is possible to upgrade directly from CCM 4.2 to CCM 6.You need to download DMA (data migration assistant) tool from cisco, then you start to run this tool on CCM 4.2 publisher and output of this tool is file with CCM configuration, then you can install CCM 6.x, installation process ask you if you want to make fresh installation or you migrate from old CCM 4.x, you choose second option and installation process will ask you for file from DMA tool (file must be stored on some network directory). After CCM 6 published is installed you must add subscriber on the new CCM web admin and then you can install it...thats all :-)

About licences: licenses are migrated automatically based on number of endpoints in CCM 4 (you can add some virtual phones in CCM 4 before use DMA tool if you want to have more DLU licences in CCM 6 :-) ) to the new CCM6.At the end you must download these "migrated licences" from CCM6 and use it with ordered upgrade PAK from cisco on cisco WEB.Output of this will be true CCM6 licences which you must upload back to CCM6.

Thats all :-) Good for you will be upgrade guide which you can download from cisco pages.

WildCards in CCM 4.1 Demystified

2009-01-09T22:10:00.000-08:00

I had Some problems understanding couple of wild cards the following examples have clarified my concepts in detail.

Numbers to Match---------------------------Route Pattern
2200–2299-------------------------------------22XX
2200–2499-----------------------------------2[2–4]XX
2200–2299 and 2400–2699------------2[24–6]XX

1231[^0-2]6[981]+

The above example illustrates only single entry resides in [], so except the range between 0-2 any single digit number can be matched with this entry. [981] means only 9 8 or 1 can occupy this region.

After all the digits are dialed, if the CCM has more than one route pattern that matches all the digits, the CCM uses the most specific route pattern. For example, consider the following scenario:
Dialed number: 555-1234

CCM route pattern matches: 555-12XX, 555-12[2–4]X

In this example, the CCM uses the 555-12[2–4]X route pattern, because 100 potential matches exist for the 555-12XX route pattern whereas only 30 potential matches exist for the 555-12[2–4]X route pattern. Therefore, the 555-12[2–4]X route pattern is deemed to be
more specific.

How to Configure EtherSwitch Modules in 2851-2821 and Changing the 3750 IOS on the EtherSwitch.

2009-01-05T20:08:00.000-08:00

In this guide i am going to focus on how to add EtherSwitch modules in cisco 2851 and 2821 and changing the IOS on the EtherSwitch. cisco 2851 can reside a 48 port EtherSwitch module. i am going to describe this step by step.

http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet09186a00801aca3e.html

1 - Remove the Steel clamping on the back to insert the module.

2 - Now insert the module and push it gently until you are satisfied the module is completely inside, this step can be a little daunting because initially it took quite a while to set up the module correctly in the slot, The module wont come up if it isn't inserted correctly, it took a number of insertions and removals until the module finally came up so keep trying if you are having difficulties in inserting the module, in the latter releases it took much less time to set up the module. cisco 24 port Etherswitch module took less time to set up i guess beacuse of the special handle provided with the module.

3 - Next step is to access the module.

4 - Go to routers CLI and give an IP address to the GigabitEthernet 1/0 interface (may be diffrernt in your case), if you type #sh ip interface brief you can clearly see one gig interface is seperatly mentioned right at the bottom of the output that is your gig interface i.e your backplane connectivity to the router. assign an IP address to the interface and a #no shut. the backplane interface is UP.

5 - now type #Service-module GigabitEthernet 1/0 session , to access the module once you have accessed you can update the Image on the Switch.

6 - To Update the IOS on the switch start the TFTPD on the PC connected to FastEthernet interface. on the EtherSwitch Module issue the following commands.

7 - make this interface routed port assign an IP address to this interface.

8 - start the TFTPD on the PC.

9 - issue the following commands on the switch CLI.

10 - #copy tftp flash: , give the required IP address and the name of the IOS file the output will show exclamation marks and the copying will start.

11 - #boot system flash:IOS-name.bin to set the new IOS.

12 - #wr er this will not erase the boot system flash command.

13 - To go back to the router CLI press ctrl+shift+6 and then press "x".

14 - #disconnect ,to terminate the session with the router CLI.