CUCM TFTP Server

In a collaboration environment TFTP service can be provided using two models:

1. CUCM TFTP Server
2. External TFTP Server

Configuration files are delivered to endpoints using TFTP transfer protocol. Configuration files share the following parameters:

1. Prioritized list of CUCM servers for endpoints to register
2. TCP port used to connect to CUCM servers
3. Executable load identifiers

In addition, the configuration file per device include the following parameters as well:

1. Local/language information
2. URLs for phone buttons (messages, directories, services, and information)
3. For gateways (e.g. MGCP), the configuration file contains gateway configuration

The configuration file can be in the following formats:

1. .cnf
2. .xml
3. .cnf.xml

Note: A key difference between .cnf and .xml that phones requesting .cnf will get the load ID from CUCM while phones using .xml will get the load ID in the XML file

The format of the file is controlled by the service parameter Build CNF Files. Navigate to System > Service Parameters > #select server# > Cisco TFTP > Select Advanced to display all parameters.

• Build None - All files are built in .cnf.xml
• Build All - All files are built in .cnf
• Build Selective - all files are built in the format .cnf.xml expect for some specific models listed below. For these models the file will be built in the format .cnf.

Device Type	Device Name
MODEL_30SPP	Cisco 30 SP+
MODEL_12SPP	Cisco 12 SP+
MODEL_12SP	Cisco 12 SP
MODEL_12S	Cisco 12 S
MODEL_30VIP	Cisco 30 VIP or DPA
MODEL_IP_CONFERENCE_PHONE	Cisco 7935
MODEL_SCCP_PHONE	SCCP Phone
MODEL_VEGA	Analog Access
MODEL_UONE	Voice Mail Port

 If a phone has an XML-compatible load, it requests a .cnf.xml format configuration file; otherwise, it requests a .cnf file.

Note: If you upload none configuration files to CUCM TFTP server such as RingList.xml, Jabber-Config.xml, Lists.xml, you need to restart TFTP service on CUCM server. Also, these files won't be replicated across the cluster and you need to upload them on each node in the cluster manually.

TFTP Process for SCCP Phones

1. Once the phone boot it will try to contact the DHCP server (using a broadcast frame) to get IP Address, Mask, Default Gateway, DNS, Domain Name, and TFTP Server IP
2. The phone will send a TFTP request to CUCM TFTP server to download the configuration file
3. CUCM TFTP server will search for the configuration file in three internal caches, then disk, then external Cisco File server (if specified)
4. In case the TFTP server find the file, it will send it to the phone. The phone will parse the file and will try to contact the CUCM server using the provided IP/Domain Name and Port.
5. If the file doesn't have the CUCM IP/Name, the phone will try to register with the TFTP server
6. In case the TFTP server didn't have the configuration file, it will respond to the phone with 'File Not Found'

TFTP Process for SIP Phones

1. Once the phone boot, it will try to contact the DHCP server (using a broadcast frame) to get IP Address, Mask, Default Gateway, DNS, Domain Name, and TFTP Server IP
2. The phone will send a TFTP request to CUCM TFTP server to download all files (not only configuration file).
3. When SIP Phone configuration changes, CUCM database will notify TFTP server to rebuild all files for specific phone with the new changes. This is applicable to phone dialplan and phone softkey as well.
4. TFTP server will update the cache with the new files
5. In case the TFTP server didn't have the configuration file, it will respond to the phone with 'File Not Found'

Note: In case the phone is running Extension Mobility (EM) and a user logged in/out, CUCM database notify TFTP server to rebuild all file for the specific phone with the EM profile details

Here are the files generated by CUCM database in TFTP Server:

SIP Configuration File Type	Model 7970/71, 7961, 7941, 7911	Model 7960/40	Model 7905	Model 7912
SIP IP Phone	SEP.cnf.xml	SIP.cnf	ld	gk
Dial Plan	DR.xml	.xml	Parameter in ld	Parameter in gk
Softkey Template	SK.xml	Not configurable	Not configurable	Not configurable

Note: They the files names vary based on the phone model

Obtaining TFTP Address

Cisco IP Phones and Gateways can obtain TFTP address in one of the following methods (in order):

• Assigned TFTP server address manually (Settings > Network Configuration)
• DHCP custom option 150
• Gateways and phones can query CiscoCM1 (ensure that your DNS server is configured to resolve this name to TFTP server address)
• DHCP option 066
• The phone or gateway can use the value of Next-Server in the boot processes (siaddr)
• Gateways and phones also accept the DHCP Optional Server Name (sname) parameter

Note: Devices save the TFTP server address in nonvolatile memory. If one of the preceding methods was available at least once, but is not currently available, the device uses the address that is saved in memory.

IP Phone Boot Sequence

 

Powering

Once IP phone is connected to PoE Ethernet Switch, it will get the required power through Cisco-proprietary PoE or 802.3af PoE.

Configuring VLAN

In this phase, the phone will be waiting for the response of CDP broadcast to get the voice vlan. If the phone is connected to a device that does not support CDP, the CDP query times out, and the phone moves to the next step in the registration sequence. The registration might if you have voice and data vlan

Configuring IP

1. The IP phone will send DHCP broadcast on its voice vlan asking for IP address
2. DHCP server will respond with DHCP offer. This offer will include IP address, subnet mask, default gateway, domain name, dns server, etc. It will include TFTP server details under option 150

Note: By default Cisco IP Phones will have DHCP client enabled. You can disable DHCP client from the phone (Navigate to Settings > Network Configuration) and configure the network settings manually.

Configuring CM

At this stage, the phone will contact the TFTP server to get its configuration file. Configuration file corresponds to the device name. This file contains information about CUCM IP/Name and Port.

1. If phone was manually added to CUCM, TFTP server will locate the configuration file and transfer it to the phone
2. If the TFTP server didn't find the file, it will respond to the phone with 'File Not Found'. The phone will send another request asking for default configuration file named XMLDefault.cnf.xml.
3. If auto-registration is enabled, TFTP server will transfer the file to the phone. If disabled, TFTP server will respond with 'File Not Found'.

Note: Phones are the only device type which can use auto-registrations

Upgrading Firmware (optional)

In this phase, the phone will try to establish a TCP connection with the first node in the priority list provided in the config file.  The phone will receive the firmware load ID and will compare it with the running firmware. If different, the phone will request/download the new firmware from the TFTP server. It will also download the RingList.xml from the TFTP server.

Note: You can verify firmware mismatch (configured load ID vs. Active load ID) from 'Unified Reporting' tab.

Registering

This is the final step where the phone send registration request to CUCM (SCCP or SIP). Based on the response, if successful, the phone will display the configure DN, button template, softkey template, etc. If failed, the error cause will be displayed on the phone screen and the phone will retry.

PVDM3 DeepDive

I have created a document on Cisco Support Forum which might be interesting for your :). Here you go.

https://supportforums.cisco.com/document/12553016/pvdm3-deepdive

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