How to Check if CCD/SAF is Working?

Step1 Verify that SAF neighborship is established between SAF forwarders.

R1#sh eigrp service-family ipv4 vrf MPLS neighbors

EIGRP-SFv4 VR(saf) Service-Family Neighbors for AS(5)

           VRF(MPLS)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.37.221.19            Gi0/1.204                12 1d00h       1   100  0  14

R2#sh eigrp service-family ipv4 vrf MPLS neighbors

EIGRP-SFv4 VR(saf) Service-Family Neighbors for AS(5)

           VRF(MPLS)

H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq

                                                   (sec)         (ms)       Cnt Num

0   10.37.221.21            Gi0/1.204                14 1d00h       1   100  0  14

Step2 Verify the at SAF Client registered with SAF Forwarder

R1#show service-routing xmcp clients

Service-Routing XMCP Clients

Codes: A - Authenticated, T - TCP

    Handle     Address                                    Port  Keepalive

AT  4          10.170.10.200                             52244    24/30 

    Client name: UCM/10.170.10.200/NodeId=1/9.1.1.20000-5

AT  6          10.170.10.201                             57333    17/30 

    Client name: UCM/10.170.10.201/NodeId=2/9.1.1.20000-5

R2#sh service-routing xmcp clients

Service-Routing XMCP Clients

Codes: A - Authenticated, T - TCP

    Handle     Address                                    Port  Keepalive

AT  16         10.45.230.10                              53076    28/30 

    Client name: UCM/10.45.230.10/NodeId=1/9.1.2.13900-10

Step3 Verify SAF routing table. You can see below the SAF Services learned from SAF forwarders and SAF Clients. Service ID 101:2:* refers to CCD Service.

On R1 SAF forwarder, you can see two CCD Services directly connected (learned from SAF Clients 10.170.10.200 and 10.170.10.201) and one CCD service learned from R2 SAF forwarder (SAF Client is 10.45.230.10).

R1#sh service-routing database

Service-Routing Database

Service ID (Service:Subservice:Instance)         Trust     Domain Owner Size

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

      100:1:46545831-3634-3441-4853-430000000000 Connected *      1       333

      100:1:46545831-3634-3441-4853-4D0000000000 Learned   5      3       333

      100:2:46545831-3634-3441-4853-430000000000 Connected *      1      1426

      100:2:46545831-3634-3441-4853-4D0000000000 Learned   5      3      1426

      101:2:8976FD5D-F82E-62BC-AB80-DF860001B241 Connected 5      4       669

      101:2:8976FD5D-F82E-62BC-AB80-DF860002ED97 Connected 5      6       669

      101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 Learned   5      3       680

Step4 You can see the contents of the CCD Service learned from SAF Clients/Forwarders.

R1#show service-routing database 101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 text

Service-Routing Database

Service ID (Service:Subservice:Instance)         Trust     Domain Owner Size

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

      101:2:AD8BC93D-A526-375D-6EFE-1BB700014E93 Learned   5      3       680

          Owner: SAF Forwarder AS(5) SFv4 VRF(MPLS)

          Sequence: 4       

          AFI: IPv4

          VRF: MPLS, Tableid: 3

          Subscription Handles:  5, 6

          Reachability:

            IPv4: 10.45.230.10:5060, protocol 6 (TCP)

          Service Data:

UCM9.1.2.13900-10sb-cluster10.45.230.10

sip:0a2d209c-6015-65c7-1071-bdaf032de992@CCMPub-SB

4XXX
3XXX

          Service Metadata:

You can see that the CCD Service was originated from sb-cluster with IP address of 10.45.230.10 and learned through SAF Forwarder. Also, the service contains two CCD patterns (hosted DNs) which are 4XXX and 3XXX.

Step5 You can verify the learned CCD Patterns on CCD Requesting clients using RTMT. Go to Call Manager > Report > Learned Patterns.

Failover SIP/H323 Trunk based on ISDN Status on Voice Gateways

This is one of the common requirements to failover SIP trunk or H323 trunk if ISDN status is down. The following configuration will shutdown SIP/H323 service on voice gateway once ISDN status changes to down. Also, it will start SIP/H323 services once the ISDN status changes to UP

Note that you need to change the interface (marked in red) based on your controller type (E1/T1) and controller number (0/0/0 or 0/0/01 etc). Also, this configuration is for SIP trunk but can be applied to H323 by changing the protocol marked in red.

event manager applet SHUTDOWN_SIP
 event syslog pattern "Line protocol on Interface Serial0/0/0:15, changed state to down" period 1
 action 1.0 cli command "enable"
 action 1.1 cli command "config t"
 action 1.2 cli command "voice service voip"
 action 1.3 cli command "sip"
 action 1.4 cli command "call service stop forced"
 action 1.5 syslog msg "SIP Services Brought Down by EEM"

event manager applet BRING_UP_SIP
 event syslog pattern "Line protocol on Interface Serial0/0/0:15, changed state to up" period 1
 action 1.0 cli command "enable"
 action 1.1 cli command "config t"
 action 1.2 cli command "voice service voip"
 action 1.3 cli command "sip"
 action 1.4 cli command "no call service stop"
 action 1.5 syslog msg "SIP Services Brought Up by EEM"

LLDP-MED

MED is an extension for LLDP that support additional TLVs. LLDP-MED supports the following three classes of endpoints:

• Generic (class 1): Basic participant endpoints; for example, IP communications controllers.
• Media (class 2): Endpoints that support media streams; for example, media gateways and conference bridges.
• Communication Device (class 3): Endpoints that support IP communications end users; for example, IP phones and Softphone.

By default, a network connectivity device (e.g. switch) sends out only LLDP packets until it receives LLDP-MED packets from an endpoint device (e.g. IP Phone). The network device then sends out LLDP-MED packets until the remote device to which it is connected ceases to be LLDP-MED capable.

The additional TLVs supported can be groups as (by default all MED TLVs are enabled):

• Capabilities TLV — Endpoints determine the types of capabilities that a connected device supports and which ones are enabled.

MED Information:

    MED Codes:

          (NP) Network Policy, (LI) Location Identification

          (PS) Power Source Entity, (PD) Power Device

          (IN) Inventory

    H/W revision: 14

    F/W revision: tnp45.9-3-1-CR17.bin

    S/W revision: SCCP45.9-4-2-1S

    Serial number: FCH1714A7PV

    Manufacturer: Cisco Systems, Inc.

    Model: CP-7945G

    Capabilities: NP, PD, IN

    Device type: Endpoint Class III

    Network Policy(Voice): VLAN 104, tagged, Layer-2 priority: 5, DSCP: 46

    Network Policy(Voice Signal): VLAN 104, tagged, Layer-2 priority: 4, DSCP: 32

    PD device, Power source: Unknown, Power Priority: Low, Wattage: 12.0

    Location - not advertised

• Inventory TLV — LLDP-MED support exchange of hardware, software, and firmware versions, among other inventory details.

MED Information:

    MED Codes:

          (NP) Network Policy, (LI) Location Identification

          (PS) Power Source Entity, (PD) Power Device

          (IN) Inventory

    H/W revision: 14

    F/W revision: tnp45.9-3-1-CR17.bin

    S/W revision: SCCP45.9-4-2-1S

    Serial number: FCH1714A7PV

    Manufacturer: Cisco Systems, Inc.

    Model: CP-7945G

    Capabilities: NP, PD, IN

    Device type: Endpoint Class III

    Network Policy(Voice): VLAN 104, tagged, Layer-2 priority: 5, DSCP: 46

    Network Policy(Voice Signal): VLAN 104, tagged, Layer-2 priority: 4, DSCP: 32

    PD device, Power source: Unknown, Power Priority: Low, Wattage: 12.0

    Location - not advertised

• LAN speed and duplex TLV — Devices discover mismatches in speed and duplex settings.
• Location identification TLV — An endpoint, particularly a telephone, learns its location from a network device. This location information may be used for location-based applications on the telephone and is important when emergency calls are placed.

MED Information:

    MED Codes:

          (NP) Network Policy, (LI) Location Identification

          (PS) Power Source Entity, (PD) Power Device

          (IN) Inventory

    H/W revision: 14

    F/W revision: tnp45.9-3-1-CR17.bin

    S/W revision: SCCP45.9-4-2-1S

    Serial number: FCH1714A7PV

    Manufacturer: Cisco Systems, Inc.

    Model: CP-7945G

    Capabilities: NP, PD, IN

    Device type: Endpoint Class III

    Network Policy(Voice): VLAN 104, tagged, Layer-2 priority: 5, DSCP: 46

    Network Policy(Voice Signal): VLAN 104, tagged, Layer-2 priority: 4, DSCP: 32

    PD device, Power source: Unknown, Power Priority: Low, Wattage: 12.0

    Location - not advertised

• Network policy TLV — Network connectivity devices notify telephones about the VLANs they should use, CoS, and DSCP settings.

MED Information:

    MED Codes:

          (NP) Network Policy, (LI) Location Identification

          (PS) Power Source Entity, (PD) Power Device

          (IN) Inventory

    H/W revision: 14

    F/W revision: tnp45.9-3-1-CR17.bin

    S/W revision: SCCP45.9-4-2-1S

    Serial number: FCH1714A7PV

    Manufacturer: Cisco Systems, Inc.

    Model: CP-7945G

    Capabilities: NP, PD, IN

    Device type: Endpoint Class III

    Network Policy(Voice): VLAN 104, tagged, Layer-2 priority: 5, DSCP: 46

    Network Policy(Voice Signal): VLAN 104, tagged, Layer-2 priority: 4, DSCP: 32

    PD device, Power source: Unknown, Power Priority: Low, Wattage: 12.0

    Location - not advertised

• Power TLV — Network connectivity devices and endpoints exchange power information. LLDP-MED provides information about how much power a device needs, power priority (for the switch to decide the order to allocate power to endpoints), and how a device is powered.

MED Information:

    MED Codes:

          (NP) Network Policy, (LI) Location Identification

          (PS) Power Source Entity, (PD) Power Device

          (IN) Inventory

    H/W revision: 14

    F/W revision: tnp45.9-3-1-CR17.bin

    S/W revision: SCCP45.9-4-2-1S

    Serial number: FCH1714A7PV

    Manufacturer: Cisco Systems, Inc.

    Model: CP-7945G

    Capabilities: NP, PD, IN

    Device type: Endpoint Class III

    Network Policy(Voice): VLAN 104, tagged, Layer-2 priority: 5, DSCP: 46

    Network Policy(Voice Signal): VLAN 104, tagged, Layer-2 priority: 4, DSCP: 32

    PD device, Power source: Unknown, Power Priority: Low, Wattage: 12.0

    Location - not advertised

Network Policy TLV

In case the network connectivity device (e.g. switch)  doesn't have a network policy configured, the network policy TLV will show the parameters received from the endpoint (e.g. IP Phone). These parameters might be assigned to the endpoint by different source (e.g. CUCM).

However, you can configure a network policy on the network connectivity device (e.g. switch) to be pushed to the endpoint using MED TLV. These parameters will override any other parameters assigned to the endpoint.

Important

While many Cisco IP Phones may support LLDP-MED, they do so only for VLAN and Power over Ethernet negotiation. Cisco IP Phones do not honor DSCP and CoS markings provided by LLDP-MED.

network-policy profile 1

 voice vlan 96 dscp 12

 voice-signaling vlan 96 dscp 13 ….. You can't assign different vlans to voice and signaling. If happened, the voice vlan will override the signaling vlan.

!

interface GigabitEthernet0/5

 network-policy 1

Note: If you assign a network policy to an interface, it will override the command 'switchport access voice vlan #'.

Link Layer Discovery Protocol (LLDP)

Link Layer Discovery Protocol (LLDP), standardized by the IEEE as part of 802.1ab, enables standardized discovery of nodes in a multivendor environment.

Restrictions:

• Use of LLDP is limited to 802.1 media types such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI) networks. It can't be used for HDLC, Frame-Relay, ATM, etc.
• LLDP and CDP can run on the same interface

LLDP is unidirectional, operating only in an advertising mode. LLDP enabled nodes will send multicast frames out of all LLDP enabled interfaces. LLDP enabled nodes which receive LLDP frames can record information about their neighbors and build their own topology database. Each node can be configured to enable/disable send and/or receive of LLDP frames as separate task.

LLDP exchange attributes in the format of TLVs between devices to discover each other.

The switch supports these basic management TLVs. These are mandatory LLDP TLVs.

• Port description TLV
• System name TLV
• System description TLV
• System capabilities TLV
• Management address TLV

These organizationally specific LLDP TLVs are also advertised to support LLDP-MED.

• Port VLAN ID TLV 
• MAC/PHY configuration/status TLV

IOS Tip: %Error deleting flash0:xxxx (Can't delete a directory that has files in it)

Have you seen this error before? Cisco IOS doesn't allow deletion of directories which contain sub-directories/files. This won't work with "delete" or "rmdir" command.

2951-router#delete /force flash0:CME9.1.0GUI
%Error deleting flash0:CME9.1.0GUI (Can't delete a directory that has files in it)








To make it working, you need to use "/recursive" keyword with "delete" command. It will start deleting using bottom-top approach from most deeper file in reverse direction..

2951-router#delete /force /recursive flash0:CME9.1.0GUI

IOS Tip: How to Move Directories within IOS Flash Memory

Have you ever uploaded a directory to Router Flash Memory (e.g. CME GUI Dir) and found that it was uploaded to wrong path? How to move it back to right path?

Let's consider a directory named CME9.1.0GUI. I wanted to upload it to "flash0:/" however, I discovered that its uploaded to "flash0:phone_loads/".

One option to put it back in the right path is to delete the directory from the wrong path and re-upload it. This can be easy when uploading from LAN or small directories over WAN. But not for big directories over WAN.

Another option is to use "rename" command. When you rename the directory, it will ask for the destination path of the renamed directory. This means that "rename" command is doing two functions which are copying the directory to new path and renaming it.

2951-router#rename flash0:phone_loads/CME9.1.0GUI flash0:CME9.1.0GUI        
Destination filename [CME9.1.0GUI]?
 
2951-router#dir
Directory of flash0:/

    1  -rw-    89934456  May 28 2013 22:07:24 +07:00  c2951-universalk9-mz.SPA.152-4.M3.bin
    2  -rw-        3064  May 28 2013 22:17:54 +07:00  cpconfig-29xx.cfg
  240  drw-           0   Aug 9 2013 04:34:26 +07:00  phone_loads
    3  drw-           0  May 28 2013 22:18:12 +07:00  ccpexp
  239  -rw-        2464  May 28 2013 22:19:54 +07:00  home.shtml
  241  drw-           0   Aug 9 2013 04:34:58 +07:00  ringtones
  242  drw-           0   Aug 9 2013 04:35:46 +07:00  CME9.1.0GUI
  246  -rw-      496521   Aug 9 2013 05:04:12 +07:00  music-on-hold.au

PS: This is applicable for any memory in IOS not only Flash.

Design Question: "dialplan-pattern" or "voice translation rule" ???

No doubt that voice translation rules are very powerful and provide many advantages in addition to digit manipulation. But let's consider a common scenario where you have CME and would like to convert extensions to E164 numbers for PSTN dialing.

One of the common ways to do this using "dialplan-pattern" command in CME. This is usually preferred over voice translation rules due to simplicity. Single command instead of voice-rule, voice-profile, assign profile to dial-peer or voice-port.

From design perspective, it is very dangerous to use "dialplan-pattern" feature. In fact I would say never use this feature. Let's look deeper.

The way how "dialplan-pattern" works that it will create an additional dial-peer for each Ephone-DN with destenation pattern as E164 number. For example, if you added a DN with number 6004 and your expansion pattern is 789.... , CME will create two virtual-dialpeers for numbers 6004 and 7896004 (you can see this using "show dial-peer voice summary" command).

Creating Ephone-DN with secondary number and having "dialplan-pattern" feature will result in 4 virtual dial-peers created (two for primary/secondary and two for E164-priamry/E164-secondary).

This means that number of virtual dialpeers is multiplied by two. For an office with 20 employees and 20 phones, you will have 40 virtual dialpeers (if only primary numbers are assigned) or 80 virtual dialpeers (if primary/secondary numbers are assigned) !!!!

Ok, till this point we didn't understand why this is a problem? What's wrong in having 80 or 100 virtual dial-peers ??

1. Dial-peers are stored in the RAM of the router for operation. Each dial peer consumes approximately 6KB of memory. 

By misusing this feature, you are adding overhead to your router's RAM without feeling it and bringing it very close to crash.

2. Assuming your are incorporating other features in your router (e.g. 2951 with default 512 MB RAM) such as zone-based firewalls, VPN, NAT, etc, you won't be able to add more than 10 ephone-DNs (assuming that secondary numbers are used). You will start getting error:

"Error: Can't Add Dial Peer"
 
3. On router reboot, although dial-peers configuration is saved in startup config, the router won't apply them to running config due to lack of RAM. This means that your router will boot with missing config (if you connect console due to reload, you will see the same error message in above point).

All of this can be resolved simply by using single voice translation rule applied to voice-port. So what do you think !!!